New town, same story…

I have recently changed employers – different industry, different structure, and different culture. I have been asked how a switch like this works for an Enterprise Architect and how transferable is the experience in EA in general. Every time this question comes up I remember a line uttered by late Patrick Swayze in the 80s classic, Roadhouse. “Ah, you know, new town, same story”. It pretty much sums it up.

Amazingly, most companies struggle with the same challenges. To name a few:

  • Too many “top” business priorities.
  • Business that proposes technology solutions rather than specifying requirements
  • Projects that define architecture only within their scope, and usually lack broader perspective.
  • Silo thinking
  • Architecture reviews, occurring way to late in the process, if at all.
  • Limited knowledge of the existing technology landscape.
  • Lack of clarity of what the architecture of the future state looks like.

Yes, the challenges are usually the same and in that sense the EA discipline has the same applicability. However, the difference lies in the approach to establishing and sustaining the enterprise architecture function. In that case the variations may be many and driven by factors like these:

Level of architecture skills within the IT organization. If the organization already has people with architecture skills but lacks architecture structure and discipline, you can focus on consolidating and standardizing the approach of existing architects. If there are no or few architects in the organization then you have two choices, hire more architects or develop architects from the existing pool of talent. In the first situation the focus will be on having the architects do architecture in a standard way, perhaps leveraging the best practices from each one of them and normalizing them using some industry framework as a guide. The second case gives you more freedom in establishing the framework first and then simply bringing the architects into it, either by hiring or training.

Level of openness of the organization to reuse solutions across established, historical boundaries. Yes, there are silos everywhere. They can be defined by organizational or geographical boundaries and are usually hard to break. The main challenge here lies in convincing the business that reuse across established fiefdoms is beneficial not only to the whole enterprise but to the individual fiefdoms too. This is a process and I believe that it is naive to expect total commitment from the entire enterprise. After all, reuse often means loss of fiefdom’s control over a piece of technology or over a process. It may be hard to swallow as it gets personal to those in charge. Strong executive leadership, especially from the business side, is the key to success in this area.

Executive support for the EA function.  When CIO (or any CxO who is in charge of EA function) understands the role of EA function, he or she can take the lead in setting the right tone in the entire organization by explaining that role. The right message and right tone goes a long way in ensuring that the organization adopts the big picture thinking and allows EA to facilitate it. Executive support is crucial and without it very little can happen. In absence of firm and vocal support, EA needs to spend a lot of energy explaining what it does and convincing the organization that its actions will benefit the company. While communication and stakeholder management are important components of EA function, it cannot be just about explaining and justifying. If you get stuck in that mode you will not have much energy left to actually DO enterprise architecture.

General understanding of the EA function. Okay, so the CIO gets it. However, everybody and their mother-in-law is an “architect” these days. Casual labeling people as architects and lack of some standardization in the role definition led to many misconceptions. Those misconceptions led to a situation that is worse than just not knowing what EA does. It created a situation where people believe that they completely understand the role of EA but their own notions are vastly different from those of other people. Moreover, they can be vastly different from the somewhat established definition (FEAPO, Open Group etc.) of what EA function is. The answer to this problem is of course, educate, show, and then educate again. This is easier said than done because once you start “educating”, you risk being seen as this theoretician who is all talk and no walk. That is why teaching must ALWAYS be accompanied by doing. Hopefully “doing” results in some quick wins that only strengthen the EA credibility and open some eyes and ears for more education.

This was not meant to be an exhaustive list of factors that influence the evolution of an EA practice. However, it seems that those are the most common ones. I have just returned from the EA Summit conference in DC and many conversations I had there seem to confirm it. In any case, EA is a journey, and we don’t walk it for the benefit of EA but for the benefit of an organization that we are part of. In that spirit, adjust EA to the organization and not the organization to EA. Flexibility, compromise, and controlled pace are the ways of the land.

Cheers. Happy EAing!

 

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.