Stopping Accidental Technical Debt

Buster Keaton looking at a poorly constructed house

In one of my earlier posts about technical debt, I differentiated between intentional debt (that taken on deliberately and purposefully) and accidental debt (that which just accrues over time without rhyme or reason or record). Dealing with (in the sense of evaluating, tracking, and resolving it) technical debt is obviously a consideration for someone in an application architect role. While someone in that role absolutely should be aware of the intentional debt, is there a way to be more attuned to the accidental debt as well?

Last summer, I published a post titled “Distance…is the one true enemy…”. The post started with a group of tweets from Gregory Brown talking about the corrosive effects of distance on software development (distance between compile and run, between failure and correction, between development and feedback, etc.). I then extended the concept to management, talking about how distance between sense-maker and decision-maker could negatively affect the quality of the decisions being made.

There’s also a distance that neither Greg nor I covered at the time, design distance. Design distance is the distance between the design and the outcome. Reducing design distance makes it easier to keep a handle on the accidental debt as well as the intentional.

Distance between the architectural decisions and the implementation can introduce technical debt. This distance can come from remote decision-makers, architecture pigeons who swoop in, deposit their “wisdom”, and then fly away home. It can come from failing to communicate the design considerations effectively across the entire team. It can also come from failing to monitor the system as it evolves. The design and the implementation need to be in alignment. Even more so, the design and the implementation need to align with particular problems to be solved/jobs to be done. Otherwise, the result may look like this:

Distance between development of the system and keeping the system running can introduce technical debt as well. The platform a system runs on is a vital part of the system, as critical as the code it supports. As with the code, the design, implementation, and context all need to be kept in alignment.

Alignment of design, implementation, and context can only be maintained by on-going architectural assessment. Stefan Dreverman’s “Using Philosophy in IT architecture” identified four questions to be asked as part of an assessment:

  1. “What is my purpose?”
  2. “What am I composed of?”
  3. “What’s in my environment?”
  4. “What do I communicate?”

These questions are applicable not only to the beginning of a system, but throughout its life-cycle. Failing to re-evaluate the architecture as a whole as the system evolves can lead to inconsistencies as design distance grows. We can get so busy dealing with the present that we create a future of pain:

At first glance, this approach might seem to be expensive, but rewriting legacy systems is expensive as well (assuming the rewrite would be successful, which is a tenuous assumption). Building applications with a one-and-done mindset is effectively building a legacy system.

Design for Life

Soundview, Bronx, NY

 

The underlying theme of my last post, “Babies, Bathwater, and Software Architects”, was that it’s necessary to understand the role of a software architect in order to understand the need for that role. If our understanding of the role is flawed, not just missing aspects of what the role should be focusing on, but also largely consisting of things the role should not be concerned with, then we can’t really effectively determine whether the role is needed or not. If a person drowning is told that an anvil is a life-preserver, that doesn’t mean that they don’t need a life-preserver. It does mean they need a better definition of “life-preserver”.

Ruth Malan, answering the question “Do we still need architects?”, captures the essence of what is unique about the concerns of the software architect role:

There’s paying attention to the structural integrity of the code when that competes with the urge to deliver value and all we’ve been able to accomplish in terms of the responsiveness of continuous integration and deployment. We don’t intend to let the code devolve as we respond to unfolding demands, but we have to intend not to, and that takes time — possibly time away from the next increment of user-perceived value. There’s watching for architecturally impactful, structurally and strategically significant decisions, and making sure they get the attention, reflection, expertise they require. Even when the team periodically takes stock, and spends time reflecting learning back into the design/code, the architect’s role is to facilitate, to nurture, the design integrity of the system as a system – as something coherent. Where coherence is about not just fit and function, but system properties. Non-trivial, mutually interacting properties that entail tradeoffs. Moreover, this coherence must be achieved across (microservice, or whatever, focused) teams. This takes technical know-how and know-when, and know-who to work with, to bring needed expertise to bear.

These system properties are crucial, because without a cohesive set of system properties (aka quality of service requirements), the quality of the system suffers:

Even if the parts are perfectly implemented and fly in perfect formation, the quality is still lacking.

A tweet from Charles T. Betz points out the missing ingredient:

Now, even though Frederick Brooks was writing about the architecture of hardware, and the nature of users has drastically evolved over the last fifty-four years, his point remains: “Architecture must include engineering considerations, so that the design will be economica1 and feasible; but the emphasis in architecture is upon the needs of the user, whereas in engineering the emphasis is upon the needs of the fabricator.”

In other words, habitability, the quality of being “livable”, is a critical condition for an architecture. Two systems providing the exact same functionality may not be equivalent. The system providing the “better” (from the user’s perspective) quality of service will most likely be seen as the superior system. In some cases, quality of service concerns can even outweigh functional concerns.

Who, if not the software architect, is looking out for the livability of your system as a whole?

To code or not to code, is really not the question

Whether or not application and solution architects should code is an old controversy that never seems to go away. Currently it’s a discussion topic on the “97 Things Every Software Architect Should Know” group on LinkedIn. Unfortunately, the question misses the point. Whether an architect codes or not on a given project is irrelevant. What is relevant is that the architect’s technical capability (knowledge and experience) should match the role(s) he or she is responsible for. In other words, not “does the architect code”, but “can the architect code”. Additionally, it is vitally important that architects not be over-committed, leaving them with a responsibility they lack the time to fulfill.

Simon Brown, on the blog Coding the Architecture”, has observed that “It’s a role, not a rank”. This role-based view is key. Simply put, the architect role architects, the designer role designs, and the coder role codes. It is the role(s) that are significant, not the title. It is fairly common to find individuals filling multiple roles. When the demands of those roles exceed either the capability or the bandwidth of an individual, trouble ensues.

In terms of technical knowledge, there is both breadth and depth. The requirements for those dimensions vary based on the role. Different individuals have different capacities for attaining both breadth and depth of technical knowledge. However, the limiting factor will be capacity for work. Even if someone has the ability to attain the greatest possible depth of knowledge across the broadest selection of domains, there are only so many hours in the day.

If we factor tasks per role, intensity of those tasks, number of roles, and number of applications, the workload on a given individual becomes clear. If that workload exceeds capacity, then some tailoring must take place to bring it back in line. Task intensity is generally a poor candidate for this type of tailoring, as reducing focus will generally result in reducing quality. Likewise, paring tasks from a given role will likely result in diminished performance. If an architect is charged with both architectural and detailed design across multiple applications simultaneously, chances are that architect will be over-committed. If this is resolved by rushing work and/or eliminating necessary tasks (communicating and collaborating with the development team; adapting to changed requirements, failed assumptions, better information; etc.), then the result is the “pigeon architect” who swoops in, deposits a mess, and flies away leaving the development team to clean up. A far better option is to reduce the number of roles and/or the number of applications that the architect is responsible for. Absent that, extending project timelines to reflect the architect’s capacity will work also.

Over the last sixteen years I have held roles ranging from developer for a single application to designer/developer for a single application to application architect/designer/developer for a family of two applications to solution architect for over a dozen applications. My current roles are solution architect for four applications, application architect for three, and designer/developer for one. Stepping away from the coding role for a number of years posed no problems; I was able to resume it easily since I had remained up to date via coding proofs of concept. I quickly learned, however, that unless I had the bandwidth to fulfill a particular role (such as detailed design) completely, that it was better to delegate that role to others than to try to get by performing it in part. I have no doubt that there are plenty of ivory tower architects, but I have a suspicion that there are even more over-committed ones.

So what exactly does an Architect do?

It’s not unusual in the IT world to have difficulty explaining what you do to your parents. It is, however, a cause for concern when your peers, even your superiors, don’t have a clear understanding. Unfortunately, that’s the case with architects right now.

Part of the problem is terminology. Terms like Enterprise Architect, Solutions Architect, Technical Architect, Information Architect, Business Architect, Database Architect, Software Architect, Network Architect, Systems Architect, User Experience Architect, Security Architect, Application Architect, and Infrastructure Architect are thrown around without authoritative definition and little agreement as to what they mean. I’ve yet to see a comprehensive taxonomy and I won’t be attempting one here. Instead, I hope to highlight some recent work in the area and contribute something of my own to help increase understanding.

The best place to start, is with some definitions. As I noted in the blog’s inaugural post, Wikipedia defines “architecture” as “…both the process and product of planning, designing and construction”. Merriam-Webster’s second definition for “architect” is “a person who designs and guides a plan or undertaking”. These definitions, in my opinion, apply regardless of the type of architect being described. All architects plan, design, and guide.

I’ve found three articles that, in my opinion, do a good job of illustrating how different architect roles relate to each other and what those roles do: IASA Sweden’s Study of Architect Roles, ArchiTech Consulting LLC’s “Enterprise Architecture .vs. Collection of Architectures in Enterprise”, and Igor Lobanov’s “Differences Between Architecture Roles”. I conclude with my thoughts on the subject.

IASA Sweden’s Study of Architect Roles

The Sweden chapter of Iasa (originally the International Association of Software Architects) commissioned a study of Architect Roles that was published in the April 2008 edition of The Architecture Journal. The article dealt with four roles: Enterprise Architect, Business Architect, Solution Architect, and Software Architect. The roles are described as overlapping (see image below) and differing in depth and breadth of knowledge as well as scope of interest. Unfortunately, the article ignores two architectural domains: Technology Architecture and Information Architecture. Additionally, the description of the Enterprise Architect is too IT-centric.

ArchiTech Consulting LLC’s “Enterprise Architecture .vs. Collection of Architectures in Enterprise”

“Enterprise Architecture .vs. Collection of Architectures in Enterprise” by Yan Zhao, PhD, was posted on the ArchiTech Consulting LLC blog on November 21. While the article was mainly focused on the Zachman Framework and how it defines a collection of architectures within an enterprise, it also illustrated the relationship of architectures (and by extension, architects) within that framework (see image below). While it leaves out the overlap, it does a much better job of showing the level at which each role works and it includes the Information Architecture domain.

Igor Lobanov’s “Differences Between Architecture Roles”

Igor Lobanov posted “Differences Between Architecture Roles” on his blog on September 19. While it doesn’t touch on the Business or Information Architecture domains, it provides the best visual representation (see image below) of the depth, breadth, and scope of Enterprise, Solution, and Technical Architects. He also captures the overlap inherent in the roles. In his model, the Technical Architect (correctly, in my opinion) encompasses both the Application Architecture and Technology Architecture domains. Additionally, Igor’s descriptions of the three roles are excellent, detailing the concerns that each role deals with.

My Thoughts

The fact that we are dealing with roles rather than positions complicates matters, because one person can undertake many roles. This is why the overlap aspect is one I consider important. I would hazard a guess that most Solution Architects serve double duty as Technical Architects (generally Application Architects) in small and medium-sized organizations. For that matter, in many cases the Solutions Architect/Application Architect may also double as a senior developer/technical lead (which has both positive and negative effects, but that’s a post for another day). As shown by all three articles, however, the roles share common characteristics differing mainly by depth and breadth of knowledge as well as scope of interest.

For the most part, Information Architecture and Business Architecture receive short shrift in the articles linked to. This is unfortunate as these domains are becoming increasingly important (Information Architecture in particular). I suspect, given recent trends, that those roles will become more common and better defined in the very near future.

Security Architecture is another neglected, but critical area. There’s still some debate as to whether it is another domain or a cross-cutting concern. That’s a debate I won’t be able to settle here.

My concept is a blend of the three articles I’ve referenced. From a high level, I like the overlapping circles of the Iasa model, but I see the Enterprise Architect as encompassing all four domains (Business, Information, Application, and Technology), with the Solutions Architect occupying a similar role on a smaller scale (fewer domains and less organizational scope). The remaining roles I listed, in my opinion, shake out as follows:

  • Technical Architect – this is more a category than a role.  Both Application Architects and Technology Architects would be considered Technical Architects
  • Software Architect – a synonym for Application Architect.
  • Infrastructure Architect – a synonym for Technology Architect.
  • Network Architect – a specialization of the Infrastructure Architect role.
  • Systems Architect – Wikipedia’s definition is synonymous with Solutions Architect, but the usage I’ve seen more commonly is that of an Infrastructure Architect dealing with servers and operating systems.
  • User Experience Architect – a specialization of the Application Architect dealing with user interface design and usability.
  • Database Architect – I view this role as a specialization of the Application Architect (big surprise: an Application Architect views the database as a component of the application), but I see it commonly falling into the Infrastructure space.

There are, of course, roles that I’ve left out. SOA Architects, Storage Architects and Active Directory/LDAP Architects come to mind, but I’ll leave it as an exercise for the reader to fit them into the framework above. It’s my hope that the framework itself is useful for understanding what to expect from these roles.