Architecture value and the KISS principle

It seems that everywhere I turn, somebody talks about the business value of architecture. People talk about it but few found a good way to measure it and to communicate it. From what I could gather, most attempts at formalizing valuation techniques for architecture take a process-heavy, formulaic approach that claims to produce a score that identifies the “best” architecture. Most of those attempts fail at that too because they forget to recognize that we as architects are usually not the ones that make architectural decisions. As shocking as it sounds, I wonder how many of us architects actually hold a bag of money to fund the implementation of the best architecture possible? I’m guessing that not too many of us have that luxury. In reality, architecture is the art of compromise where business holds the purse and architects recommend and try to influence the best architectural outcomes. It is another way of saying that architecture decisions are rarely made solely on the technical merits of architecture. Instead, they are made as a result of many technical and non-technical considerations, with those non-technical ones often being out of the sphere of influence of architects. In this light, it seems that an architecture valuation technique may be most useful if it fosters meaningful discussion with business and if it presents business-themed choices rather than singular, techno-centric recommendation.

The role of architecture is to guide the change of a system.  In absence of change, architecture is not needed. You just build something and it remains – no need to move it, no need to extend it, no need to optimize it, no need to make it work in a new context. In reality, change is ubiquitous and architecture as a planning discipline is called upon to enable and guide transition from one state to another. In a way, architecture is a little bit like a GPS device in your car. It helps you get from your current location to your desired destination. Think about it… You turn it on and it acquires the satellite signal and determines your current location. It needs to know where you are in order to plot the course for you. Then you punch in your destination and the device computes the optimal path to get there. As it computes it, it considers your preferences that you have pre-recorded in your device. Do  you want the fastest route or the shortest route? Do you want to  avoid toll roads? Do you want a scenic route?
What are those decisions if not value-based preferences? Cheap or fast? Simple or flexible? In the end almost every decision we make includes this underlying tradeoff analysis. Sometimes it is done in the open and sometimes it is done subconsciously based on our preconceived notions of value.

Trouble with architecture is that its value is often difficult to express. In most cases, good architecture will provide benefits in the long run but be perceived as expense in the near term. This is different from the functional aspects of a system. When the system is tasked  with delivering new or enhanced functionality, it is expected that there will be cost and time associated with implementation. The purse-holding stakeholders expect it and they also expect that the benefits of that new functionality will start coming to fruition soon after the new functionality is put into operation. It is trickier with architecture. Architecture of a system is usually hidden, and does not often manifest itself in flashy screens or availability of functions. More so, its greatest benefits often come into play not right after deployment, but down the road, when it’s time to extend it or integrate it with other systems. Those long-term considerations can be very elusive, especially to business stakeholders who may have trouble understanding them, especially when they are discussed in a manner that makes every non-techie’s eyes roll. Hey, business person! Do you want to talk about system’s scalability, deployability or utilization?!

Business people want to talk about business things, like time or money. They like to know what architecture means to time and money but are not necessarily interested in all the ugly details. Talking to business people in a traditional language of architecture may be responsible for architecture not being fully appreciated and consequently neglected or even ignored. It is not practical to expect business people to adopt the language of architecture. Instead, it is the architects who must arm themselves in the vernacular that allows effective communication of architecture tradeoffs and how those tradeoffs affect the value proposition of the system.

One way to approach it is to express value through a small set of attributes that encompass business and architectural considerations in a way that is palatable by non-technical people. Each attribute can then be scored individually on a predefined scale, say zero to four, with four being the most desirable and zero being the least desirable. Each architecture choice can then be described through the set of those scored attributes giving stakeholders a reasonable idea of the trade-offs between different choices.

For example, if we are looking for ways to architect a new system, we may be faced with the following choices:

  • Build – build it in-house and host it on premises.
  • Buy – buy a commercial, off-the-shelf product as the basis of the new system and host it on premises.
  • Rent – contract the SaaS solution as the basis of the new system.

Each one of those choices will have a different architecture that can be summarized through the set of attributes in a way that will illuminate the key differences.

Consider grouping those attributes in three categories: Cost, Speed, and Architecture Quality. The first two categories group attributes that should be most familiar to business as they deal with the money and time aspects of the system. The third category is more typical for architecture discussions and groups attributes that deal with the long-term technical aspects of the system.

The first category is Cost. Here we can use three attributes that look at the cost from different perspectives:

  • Implementation Cost includes all labor and capital cost that has to be incurred in order to deliver the proposed system. The lowest implementation cost is most desirable.
  • Operating Cost includes all costs, labor and capital required to maintain and support the proposed system once it is put into production. Operating cost can be expressed as an annual, or multi-year expenditure, depending on your organization’s preferences. The lowest operation cost is preferred.
  • Savings on Future Solutions includes predicted savings that can be realized down the road as a consequence of the proposed architecture. This is different from the implementation cost or operating cost of the proposed system. It is a long-term measure of savings in the future implementation costs. For example, imagine that the proposed architecture established Web API management solution for the enterprise. It carries implementation cost and operating cost. However its real cost-related benefit lies in the ability to develop applications cheaper down the road. The highest level of savings is desirable.

The second category is Speed. Here we can use two attributes that look at the time from different perspectives:

  • Time to Benefit reflects the estimate of how soon the system can begin generating business benefits. Of course, the sooner the better.
  • Enabled Speed of Solutions reflects predicted gains in speed of delivery down the road as a consequence of the proposed architecture. Just like Savings on future solution in the Cost category, this attribute is a long-term measure that is focused on the ability to deliver future solutions faster.

The third category is Architecture Quality. Here we can use four attributes that somewhat resemble quality attributes well-known in the system engineering world. The difference is that our attributes are more high-level and represent amalgamation of more detailed ones. The amalgamation is necessary in order to convey characteristics of an architecture in a way that is more palatable to business stakeholders. Another reason is to reduce the number of quality attributes to the level that is manageable, easily presentable and less overwhelming. The attributes in the Architecture Quality category can be the following, with higher score generally preferable for all attributes:

  • Security is the ability of the proposed system to prevent malicious or accidental actions outside of the designed usage, and to prevent disclosure or loss of information.
  • Performance is the cumulative measure of manageability, throughput and latency. It measures the effectiveness of the proposed system.
  • Availability is the cumulative measure of downtime, capacity, utilization and recoverability. It is an expression of run-time characteristics of the system.
  • Flexibility is the cumulative measure of maintainability, scalability, reusability, and testability. It is an expression of design and build characteristics of the proposed system.

Given the attributes defined above, we conduct the analysis of our example choices (Build, Buy, Rent) and score each attribute on the scale of zero to four. Next, we plot he results on a radar chart.

Radar

As you can see, each option has a slightly different value proposition. In our example, the Rent option seems most attractive from the perspective of all cost attributes. The Build option is the most attractive from the flexibility standpoint. Perhaps it is because that option allows us to tailor the system exactly to our needs. Build option seems to be the most attractive from the perspective of the enabling the speed of future solutions too. Why is that? Of course, you can’t tell from the diagram, but whoever scored it so high must have  had some justification for it. That justification better be recorded somewhere to justify this score.

This perfectly illustrates the key benefits and shortcomings of this approach. Foremost, this approach serves as a communication tool, which intends to generate meaningful conversations about architecture. It doesn’t provide all answers but it certainly allows quick identification of meaningful trade-offs. Stakeholders will agree with some of the scores and challenge the others. They will certainly ask for explanations. In the end, the decisions will consider, or at minimum acknowledge, the architecture trade-offs and the long-term value proposition behind them. Degree to which the long-term attributes influence that decision will vary but at least the decision will be overt about accepting or ignoring architecture concerns. This is great! At least we are talking about architecture, and not just among ourselves, architects!

There is something more to be said about the attributes. While the attributes in the Cost and Speed categories are fairly obvious and usually easily accepted by the audience, the Architecture Quality attributes may be somewhat controversial, especially for architects. After all, the arbitrarily selected four attributes obscure more detailed characteristics of the system and may be misleading. Also, in some cases one detailed characteristic may balance out another, which would lead to rolled-up neutral assessment of the attribute. Yes, this is all true. However, consider the following:

  • Discussion about detailed characteristics of architecture (quality attributes) can still occur. In fact, good analysis should occur at that level and the record of that analysis kept. Results, however, can be rolled up to foster better engagement of business in trade-off conversations.
  • Some detailed characteristics of architecture are probably more significant than others in your organization. Check what drove good and bad architectures in the past and you may  find that not all quality attributes are equally important. Perhaps it is not the ones described above. Find your own set.
  • All quality attributes are important, but discussion about most of them will make your business partners roll their eyes. They don’t have the  patience or technical aptitude to debate merits of each one. They want “executive summary” with details available only when needed.
  • English (or any other natural language for that matter) is the language we communicate with business, not architect-speak. Speaking about system availability is more natural than speaking about utilization or failure transparency. Speaking about flexibility is more natural than speaking about deployability or testability.

There is something to be said about the representation of the value of architectural choices. For our example, we chose the radar chart. It is not very innovative in itself, but it is simple and easily recognizable at the first glance. Just by quickly looking at it we can get an idea of what the trade-offs are. Again, think about the audience who would be well served by something readily recognizable and easy to decipher. With some luck, consistent presentation of the architecture trade-offs will get so ingrained in business stakeholders’ memory that they will be asking to see the architecture value chart themselves.

The approach described in this post is not a complete methodology. It is a way to categorize, score and communicate value but it doesn’t make any assumptions about who does it and how. It is expected that this method could be embedded within the established architecture process in your organization and tailored to consider unique organizational and cultural aspects of your company. We have successfully implemented this method in my workplace and chances are it may work for you too. If there is one thing that I could point to as a singular factor in success of this method is its conscious and strict adherence to the K.I.S.S. principle (Keep it Simple, Stupid). Of course there are some nuances of this method that I didn’t get into here, but I would be happy to discuss if you are interested.  Please drop me a note if you have questions.

Integrating Enterprise Architecture – practical thoughts

1902 Glider from rear

Learning to fly. We didn’t get the Dreamliner right away.

It is hard to get excited about enterprise architecture frameworks these days…or maybe it’s just me. Of course, the framework-centric “certification industry” is in full gear producing “certified architects” but just like many other infatuations this one will pass too. There is already evidence that the enterprise architecture frameworks are entering disillusionment phase where the notions of sliver-bullet approach to enterprise architecture have failed (see Gartner Hype Cycle for Enterprise Architecture). With any luck, the streamlined, practical and value oriented approach to enterprise architecture will emerge from the through of disappointment.

Does it mean that the architecture frameworks failed to deliver? Yes and No.
Yes, because they failed to deliver the silver bullet. However, in all fairness, most frameworks never claimed that they had all the answers. In fact, they usually state that the best approach is to take those elements that work for your organization, and tailor them to the organization’s specific needs. In that sense, the frameworks failed to deliver what they never promised. No, because they provided a way to conduct discussions about the enterprise architecture function in a structured fashion. As flawed as they may be, they do embody some collective architecture experience, which can be considered a best practice.

I can’t shake the feeling that many mainstream enterprise architecture frameworks are a better fit for smaller-size companies or for individual segments of a large enterprise. They seem to be assuming the process and the flow of information that are mostly undisrupted by conflicting priorities. They seem to underestimate the complexity and cost of managing architecture information on a larger scale. This is ironic because enterprise architecture by definition makes more sense for large, complex environments where aligning change to strategic goals truly is a “full-time job”.

Implementation and application of some architecture framework as the foundation of the enterprise architecture function is usually a good idea but doing it in context of a large enterprise can be challenging. There are distributed decision centers, often fragmented architectural information, large number of stakeholders,  and many, many moving parts. In this context a lot of energy goes into efforts that aim to integrate the disparate processes and information so that the enterprise architecture function can be executed in a coherent manner that is worthy of the enterprise scale. Enterprise architecture frameworks don’t provide complete answers to this challenge. Instead, they give us a picture of a somewhat idealistic future state with the hope that we figure out how to get there.

Situation like this may call for a pragmatic approach to implementing the function of enterprise architecture. To be perfectly clear, “pragmatic” doesn’t mean devoid of structure and solid footing. It means “systematic”, “gradual” and “environment-appropriate”. It means not taking the frameworks literally but applying what fits YOUR organization, and pushing for change at the pace that does not overwhelm. One way to articulate this approach is through the set of guiding thoughts that may sound like this:

  • Know why you want enterprise architecture TODAY. Focus on generating value for business sooner rather than later. Enterprise architecture usually enables good things in the future but may struggle to deliver immediate benefit. Find the immediate one! It may be in the least expected area, like using architecture models for impact analysis or project team onboarding. If you can realize short-term benefits and point to quick wins with architecture, you will be able to gain enough support to realize other, lofty goals.
  • Be mindful about how much architecture information you can manage. Enterprise architecture function has to be sustainable.  Cost-benefit analysis must be done upfront and may lead to compromises in how you describe architecture.  Favor breadth over depth and don’t be tempted by desire for more detail unless you have clear understanding of how it will contribute to the net value for business.
  • Models developed organically in silos will not blend well. Out-of-the-box modeling languages are too ambiguous to allow consistent integration across siloes. Consider focusing on a subset of element types first and establish a set of rules on top of a standard modeling language.
  • Build on the existing foundation. You already have processes. Use them, tweak them, repurpose them. Big change is expensive.
    You already have a language. It is the one that the business uses. Use it where you can and don’t force the business into enterprise architecture vernacular. Remember that the business cares about value and not about your cool architecture framework.
  • Establish architecture taxonomy first. Considering the previous bullet, build and publish the catalogs of common architectural elements like processes, applications or services. Make sure to have enterprise-wide agreement to use the catalogs when discussing those common elements.  Again, don’t force the architecture language on all stakeholders. Instead, use theirs and translate internally.
  • Establish information ownership and governance. Controlled management of change inspires trust. Whether it applies to catalogs of apps, services, or models, change must be managed to ensure that the information is reliable. However, don’t go overboard with control as it may create perception of bloated bureaucracy. Focus your control efforts on big-ticket items that are used to link information across many sources. Examples of that could be an application portfolio or a service portfolio.
    Interests of all stakeholders must be represented when the change is proposed. For that reason, establish the role a data steward and position it to facilitate stakeholder collaboration and consensus building.
  • It’s about information, not about the tools. Invest in information and ensure it is expressed in a standard way. Exiting standards like BPMN, ArchiMate or UML may be a good start. Standard-based approach increases the chance of portability of the underlying data between different tools. Start with simple set of tools and once you learn how to manage the information you will be in better position to introduce some big, expensive tool down the road, if you really need one. Vendors of “Cadillac” tools want you to believe that their offering will solve the enterprise architecture problems. Their approach often requires big upfront investment and managing information in a way prescribed by the tool. The problem is that if you don’t know what you want it will be very easy for the vendors to sell you anything. Learn where the value is first.
  • It’s about people. People don’t like change but will lie about it. You may quickly realize that in most people’s minds change is good only when it is someone else who has to change. This may be amplified in highly siloed environments where organizational and ownership structures have been fossilizing over the long periods of time.
    Securing the executive support for the enterprise architecture initiative goes a long way. Strong and firm leadership from the top with clear messaging about the value proposition is a must. Without it, you will get nods and smiles but not much cooperation. The executive support can be thought of as a stick in a “carrot and stick” combo. The carrot takes us back to the first bullet of this rambling, which talks about short-term benefits. Build bottom-up advocacy by showing immediate benefits from the integrated enterprise architecture information and play into people’s self-interest.

It goes without saying that the above thoughts may not apply to every situation. However, I suspect that at least some of them may be worth considering whenever the implementation of the enterprise architecture function is undertaken.
Enterprise architecture function on a large scale can be very challenging. Chances are that if you are reading this post, you have tried or are trying to advance the enterprise architecture in your own environment.  What are your experiences? What approach really worked for you? What didn’t? I would love to hear from you.

Aside

I will be speaking about the practical approach to integrating enterprise architecture at the SATURN 2014 conference in Portland, OR. Abstract below.

Integrating Enterprise Architecture

In the era when contributing to business value is the principal consideration of IT, large and distributed organizations face a challenge of understanding how their capabilities are realized and how they can synchronously evolve them in alignment with business strategy. Structured information coupled with efficient architecture processes sets the foundation by addressing several issues: 

  • Complex interdependent systems that evolved independently increase technical debt. 
  • Nonexistent, inconsistent, or scattered architecture descriptions make planning difficult and extend the delivery time of solutions. 
  • Unclear dependencies of business capabilities on technology lead to weak commitment to business goals. 

The TOGAF, ArchiMate, and Sparx EA tools are cornerstones of Progressive’s approach to integrated enterprise architecture. By leveraging existing systems-development life-cycle processes and architecture-governance structures, Progressive implemented elements of the TOGAF Architecture Development Method and established consistency in defining and reviewing target architectures. Investing in modeling skills and introducing standard building blocks for architecture models allow architects to describe the systems and capabilities in a uniform way that produces an overall view of the current and future states of the enterprise. This presentation presents a practical approach to implementing integrated enterprise architecture at a large organization. Specific tools, frameworks, and languages serve only as a context for this experience-based story.

I love standards, there are so many to choose from!

I love standards. There are so many to choose from!

But seriously, Survey of Architecture Frameworks compiles a list of so-called architecture frameworks. I noticed that it mixes actual “named” frameworks like TOGAF or DoDAF with languages/notations like ArchiMate and with what is probably better described as reference models. It’s okay. All of them have something to do with frameworks, albeit with varying levels of completeness.

It is a useful summary. It is also a sobering experience to see it all in one place and realize how many different approaches to architecture have been developed. It may be a testament to our quest for consistency and perhaps even obsession with frameworks. This reminds me a speaker’s statement from Gartner’s EA Summit 2013 – “…stop focusing on frameworks, focus on business value…”. We often forget why we DO architecture. Instead we put a lot of effort into implementation of architecture frameworks, striving for the cleanest, purest implementation. We argue whether ArchiMate Location element is appropriate to represent a department in an organization or whether “Customer” is better represented by a Business Role or a Business Actor. In the end, it doesn’t matter as long as we do it consistently.