The “A”-word

Everywhere I go I hear similar stories about EA teams struggling to break through misconceptions and  skepticism to provide real value to the business. So much has been said about EA value that I feel exhausted even thinking about it. Instead, I wanted to ponder the possibility that we have a branding problem and the word “architecture” is our own enemy.
EA is at its best when working closely with business, helping analyze and steer decisions, strategic or tactical. However, business often sees us as technologists only. In their eyes we are those people who can evaluate technology, size the servers, wire the applications together etc. They often don’t see us as partners in strategic alignment or innovation discussions that occur outside of the realm of IT. This is unfortunate but how can you blame them?
Historically EA comes from IT. The appreciation for architecture in IT started at the  application or the system level and only intensified as the systems became more fragmented and distributed, thus needing good architecture. It wasn’t until much later when Enterprise Architects realized that they need to develop a holistic view of the enterprise which goes beyond technology.  Unfortunately, business folks didn’t necessarily come to this realization at the same time.
People who call themselves Enterprise Architects usually “graduated” from senior development or system engineering roles. Enterprise Architect became the sought-after title that was synonymous with the pinnacle of career in IT (?!) (by  the way, I’m not trying to disparage others…I myself walked the same path). As for business, they used to speak with Software Engineers and now they are asked to speak with Architects. Guess what? For the most  part, they are the same people doing very similar work. The main difference is the title. Can we really blame the business for treating architecture as the function of IT then?
The Open  Group does not help either. TOGAF, while it features business architecture as a component of EA, it remains very IT-centric. In fact, it is very difficult to see it as anything other than a framework for developing IT systems.

Interestingly, Business Architecture now tries to surface as the discipline that attempts to provide what Enterprise Architecture failed to deliver – business-focused, value-centric approach to  architecting the enterprise. Granted, Business Architecture Guild firmly positions business architecture under the umbrella of enterprise architecture together with IT architecture. However, there are voices that say that business architecture is really what enterprise architecture should have been. This is usually  accompanied by  the statements that Business Architect is this new cool role that everyone should aspire to.  We shall see how this turns out but I suspect that the “A-word” will get in the way again. Especially that most organizations promote Business Architect role from within IT and use the ranks of Business Analysts as their basis. The challenge here is two-fold. One is that Business Analysts often reside within the IT organization, which again leads to the IT stigma. Two is that many Business Analysts usually focus on business requirement analysis and user acceptance testing. They don’t necessarily have the breadth of technical background and experience to perform in the Enterprise Architect capacity.

In any case, getting out of IT shadow without losing IT perspective is likely to continue to be a challenge for EA and using the term “architecture” is not helping. “Architecture” is not likely to be associated with more than technology by many, especially on the business side. Fighting it is counterproductive. Instead EA teams could eliminate the term “architecture” from their name and from their vocabulary. Instead, they may consider saying “strategy”, “business alignment” or something that doesn’t scream “technology”.
Perhaps EA teams could be placed under the office of Strategy Management or under the office of Business Innovation instead of some IT department.

 

Advertisements

Preaching to the choir

ApplauseIt has been a few weeks since the Gartner Enterprise Architecture Summit conference in Grapevine, Texas. It continues to be my favorite conference, probably because it seems to be the only US-based conference dedicated entirely to the EA discipline. For me, attending this conference has three benefits. One, it allows me to validate initiatives and approaches, that I as an architect push within my organization. Two, it allows me to have numerous conversations with my peers about the state of their EA practice. This is, of course, invaluable because it puts the “reality” lens in front of what Gartner says. Three, it exposes me to information about developing trends in EA.

At the last conference, one of the recurring themes appeared to be “Vanguard EA” and how it plays in the era of digital business. The key premise here is that the Vanguard EA is the part of EA discipline that is about looking into the future, about innovation, and about steering the enterprise in close partnership with Business. This is in contrast with the Foundational EA, which is more about traditional, perhaps more reactive and IT-focused practice. In other words, Foundational EA is what most EA organizations are today, while Vanguard EA is this emerging trend which represents the place where most EA organizations would like to be. From what  I  could gather, Gartner believes that there will always be room for both Foundational and Vanguard EA, but in order to thrive in the digital business era organizations must evolve their EA practices beyond their foundational character.
This is great and I couldn’t agree more. Here is the disconnect though… Virtually in all hallway conversations I had at the conference, attendees confirmed that the idea of Vanguard EA is a very elusive dream, as most EA organizations still struggle to be invited to  the “business” table.  It is true even for what Gartner would consider foundational  EA work. In  one of the sessions, Gartner speaker suggested that we as Enterprise Architects should invite ourselves to the business table,  by demonstrating the value that  we bring to business discussion. This is nice, but also strikes me as a little whiny. It’s like a kid saying that if another kid doesn’t want to play with him then he would just keep  bringing him candy in hopes that one day he invites him  to  play. This is a precarious position to be in… and it brings me to the point of this post. It seems that Gartner may be preaching to the choir. Don’t tell us, architects that Vanguard EA is a way of the future, tell the business!

I don’t have the official statistics but I am willing to bet that the vast majority of attendees were architects or managers of architecture organizations. Very few attendees were true business leaders. In one of the closing sessions, the audience was asked “how can we make this conference better”. One of the attendees responded, “offer a two-for-one deal, where you get your conference pass for free if you bring a business person with you!”. I’m not sure if this particular idea is feasible but it clearly shows that many of the attendees share my sentiment. So how about it Gartner? Perhaps it is time to stop preaching to the choir and direct your message to business leaders instead.

 

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.