Connecting the Dots: Strategy to Architecture to Execution

#enterprisearchitecture #strategyexecution

The Challenge

How often, as Enterprise Architecture (EA) practitioners, have we walked into large organizations and were confronted by islands of solution & development teams? And how often did we deduce that these islands were exactly that – siloed teams, often working against each other’s interests, and at loggerheads with the organization’s larger business and IT vision? And if we dare ask these teams one of EA’s favorite questions, “are you folks aligned with the organization’s strategic business and IT objectives?”, what would be the most likely response?

We in the EA community and elsewhere in IT are given to lamenting about silos on a regular basis – siloed work environments, siloed teams, siloed (and conflicting) IT standards, and on and on and on. So what causes silos in the first place? A few popular reasons include, but are not limited to:

• Periodic mergers and acquisitions cause the enterprise to grow rapidly. Political, financial and other pressures compel the enterprise to “put off” rationalizing the teams, the silos are allowed to thrive, and become even more problematic for the organization down the road.
• The organization embarks upon?new business ventures, and each such business venture demands its own IT group because the new business is somehow special and has its own unique requirements that the existing IT group cannot meet.
• Even new product lines introduced by an enterprise can cause separate solution teams to be formed. Sooner or later, due to time-to-market pressures and the like, the solution teams become micro-organizations in their own right, and operate more or less independently of one another.

While all this is going on, the IT leadership, more often than not, is watching helplessly. And before they know it, the problem has gone out of hand and renders itself too complex and expensive to resolve. Therefore any new major strategic initiative takes a longer time to percolate down to the lower rungs of IT impacting the time-to-market efficiencies. Even worse, large, enterprise-wide initiatives may be required to be implemented by multiple solution teams. Each of these solution teams may well follow different approaches to software architecture, design and development, and not necessarily contribute towards a single consistent and a high-quality outcome that benefits the enterprise as a whole. This effectively signals a breakdown between what is actually implemented and what was originally envisioned at the strategic level in the enterprise. All this, by the way, is often happening while there is an EA organization functioning in the enterprise!

In my own experience, I have many a time?encountered this idea that EA somehow should stay within the boundaries of architecture development, but avoid active involvement in solution and the rest of downstream software development activities. Sure, EA can recommend standards, best practices, reference architectures, etc., but it is more a case of publishing the material and hoping the consumers would use it as intended. EA does not necessarily have a solid mandate to follow through and ensure these standards, best practices, etc. are being adhered to. Why? Because, you know, EA can prescribe laws, but not necessarily enforce it!

The end result then is rising entropy in the solution and development teams in the IT organization. This then leads to industry observers, commentators, and the like pointing fingers at EA and saying how much out of step, or how ineffective EA is (or has become) in the real world. Some of these observations are actually justified and well-deserved to be honest!

The problem, in my humble opinion, is EA’s inability (thus far anyway) to connect the dots from Strategy to Architecture to Execution. This link, especially between Architecture and Execution, is not always addressed seriously, and perhaps not even considered to be sexy enough to be paid much attention to in the EA community. We have done a decent job linking Strategy to Architecture, but this pair continues to remain somewhat disjointed from Execution. This is problematic because the simple truth is, Solution Architecture and Development teams are one of the primary consumers of EA!

The ‘Strategy to Architecture to Execution’ conundrum may be resolved by addressing the three principal and related concerns that come to mind – People, Process, and Technology. This approach thereby would alleviate the silo-related problems to a large extent.

People

Let’s begin with examining the People concern since it is the easiest to address, right? Who are we kiddin’…of course not!

Firstly, in order to get EA to seep a little deeper into the solution development organization, there needs to be an unequivocal mandate to do so from the senior IT leadership. The key here is, EA (or some equivalent governance body), must have teeth to rein in errant solution organizations if it becomes absolutely necessary. And quite obviously, to obtain the solution teams’ buy-in, the EA organization has to set in motion an ongoing communication plan that informs and educates how and why EA can help to make the solution folks’ lives that much easier. No easy task, but it has got be done nevertheless.

Even in the case of multiple solution teams that may exist in an organization, embedding enterprise architects in these teams who can work in closer proximity with the solution folks would be a good idea to ensure there is closer alignment between architecture and execution. Having multiple solution teams is fine as long as they are mandated to anchor to the same EA architecture & standards. The necessary prerequisite to making this a successful endeavor is to ensure that solution teams can avail of timely, easy, and adequate assistance in this regard. A large part of realizing this prerequisite has to do with the Technology concern that we will examine shortly.

In this age of gamification and other contemporary techniques to encourage or foster a certain kind of behavior in a group, EA (and the IT leadership in general) should be getting creative to develop the required sense of ownership and commitment from the solution teams. A simple example of gamifying in this case would be measuring the extent to which reference architectures or patterns are reused in solutions. This would be a great metric to keep track of and it would also become the basis for rewarding the consuming solution teams that adopt ‘reuse first’ (with adaptations perhaps) rather than reinvent constantly.

Organizationally, the intent is not to make EA a bottleneck in the day-to-day functioning of the solution teams. But at the same time, I would strongly suggest that EA must play a deeper role in solution architecture consultation and validation. Agile EA is still very much the desired vehicle to deliver value to the enterprise as discussed in further detail here.

Process

EA processes are pretty well-understood and well-executed today. Examples include strategic planning (business and IT), reference architecture development, roadmap planning and execution, etc. However, again in my experience, the involvement of EA in project portfolio planning or in project execution & delivery processes is still rather thin. Why is this an important issue?

Project portfolio planning involves project scheduling that is driven by resource availability, cost, DevOps'?readiness to deploy new solutions, etc. These parameters can and do affect important decisions that are made in the solution architecture & development processes, often leading to unanticipated long-term divergence from the original architecture vision as may be defined by EA. This divergence is often fondly referred to as technical debt. And technical debt is a major contributor to entropy in the solution / application landscape in an enterprise.

The involvement of EA in project portfolio planning can at least mitigate technical debt in the best way possible by recommending acceptable workarounds, and solutions to remedy the workarounds in later releases of the solutions. One would also expect EA to be involved in conversations with the business sponsors to discuss costs and thereby the optimal solution that can be delivered within the identified constraints.

The presence of EA in solution execution and delivery may be less deep, but still important since the EA function can serve as guardrails during the solution execution process. Obviously, what is being suggested here is that EA, while it is primarily about strategy and enterprise architecture definition, is not exempt from influencing or guiding the later stages of architecture implementation in the enterprise! This idea is not really new since TOGAF 9 does prescribe a similar approach as part of Phases E, F and G in the ADM (Architecture Development Method). But as we all know only too well, describing?this idea as part of a methodology is one thing, but actually implementing it in the organization is an entirely different ballgame.

Technology

Here’s where we can make some significant advances towards better integrating Strategy, Architecture and Execution. We are currently witnessing the advent of advanced EA tools and repositories that allow development of architecture models in Archimate, as well as supporting UML for the development of solution architecture and design models. These modeling environments are complemented by varying set?of capabilities to set up application, service and other EA portfolio inventories. Tools such as Software AG’s Alfabet are more sophisticated in this regard in that they provide advanced analytics capabilities in addition to the basic repository / portfolio management functions. Alfabet, for example, also complements the ARIS modeling tool (Archimate and UML) very well although there are some gaps that need to be addressed here. Cheaper tools such as Sparx’s Enterprise Architect provide modeling environments for Archimate and UML, but they still have some ways to go before they become a full-blown EA modeling and repository suite.

In the context of this discussion, however, I would submit that the current tools in the market have fallen short particularly in terms of addressing the Architecture to Execution link.

The above graphic suggests that in order to establish a truly effectual path that would lead?us from Strategy to Architecture to?Execution:

• There needs to be a seamless integration and mapping, with out-of-the-box support, between the EA portfolio elements located in the EA repository and the architecture modeling environment (Archimate). This enables ease in the reuse (and governance) of architecture building blocks while modeling reference architectures, patterns, etc.
• Likewise, there needs to be out-of-the box support for a direct mapping between EA and solution architecture models via UML Profiles (significantly enhanced in UML 2). Solution models in UML should be developed by directly reusing application, service and other relevant building blocks, many of which may be represented in?Archimate models. This ensures that disparate solution teams are still anchoring to the same EA building blocks. Incidentally, the process of deriving concrete objects or components from?higher-level abstractions of architecture or design models is known as reification.
• Most solutions conform to?an n-tier?architecture style. Therefore, there is no reason why EA tool vendors who provide both Archimate and UML capabilities, cannot provide out-of-the-box UML Profiles that model the typical solution architecture. The same idea can be applied towards business / application service and API specifications. These profiles may be then extended for specific solution needs. Prominent architecture patterns used in the industry should be available out-of-the-box and easily applied in solution frameworks. Moreover, the solution designer should be able to map the solution components directly to the EA portfolio elements, or create new ones where necessary and inject the same into the EA governance process, which may also be implemented in the same EA toolset. And do I need to say that all this should be possible via a user-friendly palette-driven environment?!
• Architecture standards, patterns and best practices should all be placed in the same central EA repository and should be easy to consume as part of the solution architecture and development practice. Indeed, this would imply that EA and SA tools must converge seamlessly towards a single unified environment that supports and enables the Strategy to Architecture to Execution linkage!?And yes – solution team(s) in organizations should be on-boarded onto this single unified environment.?This idea of a unified environment is a logical one that may typically constitute one or more tools / repositories in a physical realization. The key here is that these components?should interoperate transparently to the end-users, and must not become an impediment to the Strategy-Architecture-Execution integration objective.
• Lastly, EA tool vendors must provide advanced reporting and document generation capabilities to produce architecture and design documents from the solution models with little manual intervention. This is a no-brainer since we all know and recognize that much time is spent in documentation and this fact even causes a sense of resentment among architects and developers to document adequately in the first place. And I don’t have to spell out what happens as a consequence of inadequate or inconsistent documentation of our solutions!

In addition to the ideas listed here, we have emerging technologies such as IoT (Internet of Things) that may be infused into the EA function as discussed here.

What Next?

Of the three concerns just discussed to enable the seamless path from Strategy to Architecture to Execution – People, Process, and Technology – I believe the Technology concern, if done right, can serve as a powerful catalyst to get the People and Process aspects going in the right direction.

With People, there is always the psychological element that perceives easier and temporally efficient ways of doing things as generally being better than others! Technology can surely help here big time. Likewise, with Process, semi-automated ways to perform project portfolio planning, application portfolio management, and project governance can enable a relatively frictionless path for imbibing EA in solution planning and development activities.

Obviously, Technology is not a panacea for everything that may be broken in enterprises today from an EA or solution development perspective. But I’m certain of the fact that the incredibly wide spectrum of opportunities available for Technology to make a difference towards resolving the Strategy to Architecture to Execution conundrum is vastly under-exploited today. Indeed, EA tool vendors have just begun to scratch the surface, and I believe it’d serve these vendors very well to partner with practicing enterprise architects to bring to market, practical and real-world capabilities that will make EA a genuine must-have?and valuable function in any medium- to larger-sized enterprise!

Merry Christmas, Happy Holidays & Wishing you all a Successful, Prosperous and a generally Terrific 2016!!