How do EAs Achieve a Balance between Aspiration and Practicality in defining Future State?

EA is all about change and transformation, however, when Enterprise Architects are envisioning 'to-be' future states, how to get the right balance between what is achievable and what is desirable?

There are many things that have to be taken into account such as the maturity of the company, its business, its goals, its technology landscape, etc, also statistically, most organizations over-estimate the changes in business from year-to-year but underestimate changes over 3-5 years, so what’s the best approach?

1.    Have Multiple Views to Describe the Future State

Usually one can come in the future from two directions - where you are now and where you would like to be. So if you are envisaging five years out, you could take what you know of the current situation and build out in our minds from that. This would tend to be the cautious approach as one might choose if one were to be involved in the delivery. 

The converse approach would be to try and put the current state into a far corner of your mind and focus on defining what would appear to be the goals of the business in five years and how the organization and systems would be structured to meet that.

Both have risks: If you go for the former, you may not make the leaps of ingenuity needed and if you go for the latter you may end up defining a state that doesn't get realized. So how do you get this balance right? Try to have multiple views to describe the future state. Of course, you will need to tailor the communication of these views to different stakeholders

• The visionary view can be unconstrained by your current situation and need not be granular in detail. The futuristic EA works backward from an expected future state. 

• The pragmatic view will be more granular and will include inputs and constraints from your current state, while engineers still work forward in time even if they are iterating alternatively on the solution and the definition 

• Multi-dimensional change views: People often talk about 'change' as though it was uni-dimensional, or a universal commodity, but the type of change makes a huge difference, particularly change that follows vs. change that leads or innovates. Organizations that are fine at following often find it impossible to lead, or at least to do so effectively; as the thinking, culture, and control requirements are so different. 

The question is about balance but the answer is not as simple as whether you start from the beginning or the end. It is not a duality, like black and white, but a very complex process. The future state is very fluid. It can be defined in the present moment but will change while we are trying to reach it. In the end, the answer about balance is "it's both."

2. Transition States Describe Architectural Steps along the Way

Due to its length and sensitivity to a large number of variables, an EA design is like a sea voyage in uncharted waters. There are requirements and constraints because the world constantly changes and no-one can really predict the future. You can be as inspirational as you wish about your target architecture, but you must keep your feet on the ground for the next transition architecture up on your road map. The farther into the future the architecture is planned for, the lighter the treatment it should receive. So an architecture planned for over one year down the road should probably stay at the conceptual level.

• Transition States describe architectural steps along the way. They are shorter-term views. It's more art than science, but the Transition States can be realized without waste or false starts by characterizing the rate of change or "volatility" of various components. For some organizations, infrastructure changes less quickly than use. For others, the opposite is true. In any event, keep the "Time" domain in the architecture; use the Transition States, and review each component at twice its rate of (potential) change. 

• Another way to think of this is in terms of a plot of Certainty vs. Time vs.  Risk. The further out in time you go, the higher the risk of disruptive changes, as well as the lower the rate of certainty. For example, identifying which technology will ultimately be dominant is a high-risk endeavor, and instead focusing on the broader concepts of what parts of technology align with your business goals and only taking action where the risk/reward is the most predictable is the way forward. 

• Plan for various capability increments to achieve milestones and when scope changes as per market conditions, stakeholders priorities, etc, then there is a requirement of Architectural oversight to see at which state ( Transition State) you have arrived and what level of transitions are required in future based on business priorities. 

3. Three “C”s in EA Design

 If architecture is about describing structure and balance and relationship, then it should allow for different implementations or technologies to be exchanged over time. The future enterprise state may change though as the market conditions change, every so often. Changes should cascade down from goals and vision or be proposed for practical reasons by the program. The "to-be" architecture is incrementally achieved by iterating through the "as-is" architecture and should not be a "leap of faith" based on a grandiose vision of the desired state. And an effective EA will embrace a few "C" words: Cascading, Context, and Concentration. 

• Cascading: Future is full of curves and bumps, the challenge is the time frame need for realization of the solution - if the environment in which the proposed solution is being realized could change significantly in the realization timeframe, then your conceptualization of how the solution will interact will no longer be fully valid 

• Context: Future should be relevant to today, EA is all about bridging the future and the current state, so context is critical; EA framework should coordinate with other frameworks like Business Planning, Project/Program Management and Operations Management to plan various capabilities. 

• Concentration: Future takes focus, how to concentrate on what's most important to compete via well aligning the business resources & process, EA creates business synergy via optimizing business processes, capabilities. etc.

 

4. Enterprise Architects’ Responsibility

 EAs acts as a bridge to work with both business and IT  as they are a part of a team. Different parts of the team can take a different view & vantage point and build from there. The most effective EAs keep their feet on the ground by being actively involved with development teams; also the most effective EA visions come from close collaboration with business leaders. 

• EA has to be the voice of reason in strategy discussions and take a stand on a realistic and achievable "to-be" architecture based on the maturity and capability of the "as-is" architecture.

• The most effective EAs benefit from ongoing "close collaboration and being in-tune" with:
  - Technology and the Development teams (Tactical)
  - Visions come from with business leaders, customers, and the marketplace (Strategic)
  - Flirting with the what-if scenarios with both of the above actors (Futures)
  - Mentoring both of the above in areas where either of the above lack (Communication)
  - Hands-on in both Tactical and Strategic (Credibility) 

•  The role of the EA then becomes that of a facilitator, arbiter, consolidator, and conductor. And it is not split business or IT but have people focused on Future-Back and Current-Outgrowth teams with both technical and business people. An effective EA is also pretty much akin to a conductor of an orchestra, bringing out the best from all the talented musicians and pleasing the audience.

Therefore, EA starts at the beginning and at the end and continue to adjust based on the changes that happen along the path. That's why EA, like life, is all about transition, and transformation.

Posted in: All about Future,EA