Originally published by the Enterprise Architecture Leadership Council @ Corporate Executive Board – Jan. 2014\
There are many quotes that could be used as an allegory for EA; the ubiquitous “fail to plan, plan to fail” comes to mind almost immediately. However, another quote that comes right to my mind is one from Mike Tyson in 1987: “Everybody has a plan until they get punched in the face.”
Mike Tyson was referring to the cold hard reality that hits you when you’re standing squarely in the ring. You’ve finished preparing for the fight and all that’s left to do is see it through to the bitter end. The power in Mike Tyson’s punches was so great that an opponent would be lucky to be standing, let alone remembering his fight plan, after just one hit.
For a boxer, the fight plan is based on certain conditions, expectations, and parameters, as well as a presumption of his/her preparedness for the fight. The plan is formulated through close engagement with a number of important specialist team members—a physiotherapist, nutritionist, psychologist, maybe a performance analyst, and most importantly, the coach. Collectively these specialists could be considered the strategists of the boxing ring, with expertise in delivering the tools and knowledge for their boxer to prevail, round after round.
With that strategy in place, the boxer can then be considered the tactician. Responsible for understanding the plan, and committing to the plan to ensure he/she has the objective in mind and the greatest opportunity for success. But once the boxer is in the ring, ultimately, the tactics to reach the end goal will need to be adjusted based on real-time changing conditions.
However, that doesn’t mean the Boxer is left to his or her own devices during the fight. After each round, there is time for the coach and team to consult and advise the boxer, and for the boxer to get advice from the team on his/her condition and their observations of the opponent. Smelling salts may be provided to sharpen the senses, petroleum jelly applied to stop bleeding, and wrists may be re-strapped where the boxer is experiencing discomfort. This consultation occurs round after round so that strategy revisions can be decided along the way, based on expected point count.
Mike Tyson’s famous quote and the way a boxing team approaches a fight is particularly relevant when we consider the disciplines of Enterprise Architecture (Architecture Planning) and Solution Architecture (Architecture Delivery) and how they should work together. Enterprise Architects are the strategists, the team of specialists that formulate the plan, while the Solution Architect is the tactician, the individual that must use his/her available resources to execute to the plan to realize the desired objective. Of course, there are areas of specialization in each of these disciplines, however, the nature of the relationship that should exist between Architecture Planning and Architecture Delivery is still the same.
As with my analogous boxing team, there are many types of strategists that we refer to as Enterprise Architects. They have particular backgrounds that are necessary within an organization at a point in time. They are typically highly experienced in their domain and are in touch with industry directions and their domain of expertise. In the same way, Solution Architects, our tacticians, have a specific skillset. They interpret the plan, ask questions, focus on areas of uncertainty and risk that need mitigation, raise issues with strategists, and use all the resources made available to him/her to successfully execute the strategy.
Drawing further parallels with our boxing team analogy and these architecture disciplines, the strategists of the boxing team are not locked in offices, engaging almost exclusively with senior executives, drawing pictures of each round and recommending punch combinations to the boxer based on previously observed knock-outs. They don’t just show themselves on rare occasions before and during the fight to answer questions with an air of righteousness. No, as the analogy expressed, the strategists are committed to the boxer as much as the boxer is committed to the plan. They ensure that the boxer has everything he needs before the fight, during the fight and then after the fight, and if need be, the strategist may just have to help stop a fight by “throwing in the towel,” because the strategist is as deeply committed as the person throwing the punches.
But let’s be honest, there aren’t such close relationships between Enterprise Architecture and Solution Architecture disciplines in enterprises today. So how does such a chasm develop between Enterprise Architecture and Solution Architecture?
Firstly, it’s important to highlight that I don’t believe the current situation is a failure of individual professionals. For many enterprises, with the rush to adopt Enterprise Architecture frameworks as a means to improve Architecture Planning, many organizations have failed to take stock of what is required to execute the plan, or in other words, what the Architecture Delivery disciplines require to be a success. This has led to many Enterprise Architects having a uniquely hands-off approach, without any responsibility or accountability for realizing the plan.
Keen observation across a number of enterprises identifies many factors that have contributed to this situation. Here are a few:
- Lack of organizational ability to quantifiably define and measure EA Practice performance
- Failure to appropriately adapt a proven Enterprise Architecture Framework to the organization
- Adoption of frameworks that do not sufficiently address the interfaces with Architecture Delivery
- Inexperience of practitioners in architecture delivery
- EA practitioners who have spent too much time abstracted from the reality of architecture delivery.
As Enterprise Architects, and leaders of Enterprise Architecture practices of varying maturity, perhaps we need to take stock of, and measure our worth against the strategists of the analogous boxing team. Here are a few areas to reflect upon.
Teaming
- When was the last time you sat beside an Architecture Delivery project team for an extended period of time and actually mopped up the proverbial blood with Solution Architects?
It is only through spending time embedded in Architecture Delivery roles and activities that we can maintain relevance to a field of experienced professionals who have dedicated their careers to delivering outcomes that are unquestionably measurable. It is a mistake to think that as Enterprise Architects we are more experienced and knowledgeable than a Solution Architect, because the disciplines require different types of experiences. - Have you established the correct team composition for your Enterprise Architecture practice? Have you covered the bases necessary for your Architecture Plan?
Diversity of experience and specialization is important, but so are high levels of emotional intelligence. A team lacking the ability to develop personal relationships and read non-verbal signs of stakeholders and project delivery teams is limited in its ability to identify and address issues early. It should no longer be acceptable to dispense with our responsibility for seeing the plan become realized for the enterprise; and close working relationships are critical to doing so. If the team composition is not right to realize the plan, it needs changing.
Resources
- What physical architecture artefacts (models, patterns, standards, etc.) have you published in a way that can be effectively reused by the Solution Architect?
Heading into 2014, it is surprising to find many large organizations that have failed to establish a formal, structured, repository for architecture storage, management, interrogation, and retention. An architecture that cannot be reused is ultimately devalued. - What tooling have you made available for the management, discovery, and reuse of architectures?
The continued exclusive use of Microsoft Visio or, worse still, a variety of non-integrated tools depending on the type of Architecture being developed, will continue to degrade the value of enterprise architectures. Do boxers continue to use the same old boxing gloves and training methods of the days of old, or do they adopt new proven glove technology and training approaches to maximize the opportunity to be successful? - Have you formalized an Architecture Delivery framework and/or standard?
Regardless of how implementation is undertaken, without a defined process and templates for Architecture Delivery that ensure completeness, consistency, and domain coverage, Solution Architecture will be less than efficient or lack demonstrable alignment to the Architecture Plan. Like Architecture Planning frameworks such as TOGAF and FEAF, there are Architecture Delivery frameworks such as DoDAF and/or methods and standards such as 4+1 and ISO/IEC 42010 that provide guidance and rules for defining, structuring, classifying, and organizing architectures.
Processes
- What processes have you implemented as a formal method for incorporating change into published strategies, standards, and architecture models based on Solution Architecture feedback?
This is more than communities of practice and weekly conference calls. Often there is too much talk and not enough action. Structured and actionable methods of change initiation, review, and approval need to be implemented and, of course, measured. Otherwise Architectures become stagnant. - What processes or practices have you implemented to identify, rapidly respond, and support Solution Architects when risks and issues are raised?
How often do you review the risk and issues log of projects and call the Solution Architect and enquire about delivery progress. The difference lays in how active and engaged we are in the realization of the Architecture Plan. Personal engagement and commitment to the success of a program/project builds an Enterprise Architects credibility.
There is no doubt there are many areas in which Architecture Delivery practitioners can also improve. This discipline warrants a deeper assessment of its own. Nevertheless, as practitioners of Enterprise Architecture we need to do more than can be reasonably defined within an EA Framework.
If we are, arguably, viewed as senior representatives of ICT Architecture in an enterprise, then we must look beyond abstracted role definitions and instead critique our purpose and performance within the context of the support we provide Architecture Delivery practitioners in the achievement of tangible business solutions, outcomes, and benefits. For ultimately, what good is the perfect plan if we’ve not considered what will be required to achieve success once our fighter is in the ring?
