Let the Budgeting Process Begin – EA’s Role

As the annual corporate budgeting season begins, we find ourselves again fielding client inquiries about the role that EA should play in this annual rite.  Like many such EA best practice questions, there is the EA purist answer and then there are the many variations of more practical answers.   

In an ideal world, enterprise architecture should have little to do directly with the annual budgeting process, per se, but instead be feeding the portfolio planning process.  We “inform” that process, which should be complete before the budgeting process begins.  The analysis of strategy and business capabilities enables the creation of a holistic enterprise architecture future state, and the comparison to current state charts a forward-looking roadmap and transition strategies.  That work provides the list of potential major investments, supplementing the list of projects that is the typical starting point for the investment process.  The budgeting process systematically transforms that list of “potential” investments into those that can be achieved in the next planning cycle based on available funds, resources, risks and business priorities.   EA’s role is to impartially analyze the list of potential investments and guide the organization through the implications of various scenarios.

From a practical standpoint the reality is rarely that straightforward.  For example, there often isn’t a portfolio planning process distinct from the budgeting process.  What the organization can afford, therefore, is a dominant constraint before strategic or even tactical outcome can be thoroughly analyzed.  The EA team must never be arm’s-length if our mission is to impact the choice of projects and guide the evolution toward the desired future state.  

Another reality is that, in many organizations, the future state is rarely well-formed.  As such, most EA teams must leverage the opportunities provided by projects already on the list.    Being active in the budgeting process is a fail-safe to learn about business opportunities they might not have seen, to gain new insights into the priorities of the organization, and to discover paths that will help bring potential future states into focus.

There are other answers to the EA role in budgeting question as well, not the least of which is dealing with management expectations.  How far enterprise architects should engage, and at what level, is situational and we’d be happy to discuss offline with anyone that is interested. 

Remember, EA should not be constrained by the list of funded projects but should focus on reconciling long and short-term interests.  We should never confuse or stifle the “out of the box” thinking that EA should provide with the realities of short-term investment and implementation decisions.  EA involvement in the budgeting process is probably too late in the overall investment decision-making continuum, but it can be a good place for the EA team to ask the questions that would demonstrate the need for more proactive and broader planning in the future.

EA Principles Have Little Value

Just recently I learned that a client’s CIO leadership team began a detailed and substantive discussion on EA principles, the implications they carry for their organization, and how they can use them to transform their journey into the future.   I don’t see this as often as I’d like.  While gaining that level of leadership engagement in the creation and use of EA principles has long been a desired outcome, it is still somewhat rare.  In this case, it was a combination of good luck, good timing, and a skilled Chief Architect who was able to keep principles visible and to broker the discussion with leadership.  There is a lesson to be learned here.

With common sense as a significant part of a good set of EA principles, it is easy for a leadership team to write them off as “a statement of the obvious” and not pay much attention.  As enterprise architects, our goal must be to make principles relevant.  The approach is for us to demonstrate how they are used in practice and to show that they are more than a collection of catchy phrases.

For each principle individually, and for the set as a whole, it is important to be able to explain them in real-world terms.  This means choosing principles that guide desired behaviors and explain their rationale and implications in a form that leaders can relate to, with an emphasis on how they affect decision-making at all levels.

Unfortunately, I see many examples of principles that don’t gain traction.   When that happens, EA principles have little value.   When I diagnose the situation I often see that a lot of energy was consumed in creating the perfect written words, with less energy committed to bringing the principles to life.

A few tips:  Always be sure to include rationale and implications, but don’t worry so much about making them perfect, just strive to make them good enough.  Invest the extra energy in bringing them to life in four ways:

1. Ensure that ALL members of the core and extended EA teams understand what the principles really mean and how they are used
2. Be sure to actively and visibly reference the principles in the process of creating future state EA content
3. Refer to the principles and use them as a test in ALL solution architecture and coaching work
4. Carry the principles with you in discussions with leadership at every opportunity

By using the principles every day, their value will eventually be self-evident and leadership teams will recognize them as a helpful tool in their management arsenal.

A Simple Test for Analyzing EA Program Effectiveness

Many EA programs we examine suffer from one problem; they are mired in the details of a few narrow problem spaces and, as a result, are not as broadly focused as they should be.  A simple narrative-based analysis can help EA teams find the right level of detail for their work.  The narrative, while deceptively simple, reveals a lot about just how effective an EA program is, our how effective a new one can be.

The narrative leads to a simple test, one that is not objective and wouldn’t stand scrutiny as a well-constructed metric.  Instead it is in the form of a subjective analysis.  It is meant to focus EA leaders on one aspect of EA;  to drive consistent, enterprise-wide convergence towards a desired  future state enterprise architecture.  The premise is simple, that no matter how “perfect” and detailed the architecture, it will only make a difference to the organization if it is relevent, well-understood, it informs decision-making, and it is uniformly applied to the project and asset portfolios of the enterprise.  

The test begins by “imagining” the behavior of three (3) different project teams, all assigned the same exact project (out of the set of any projects that are typical for the organization). The teams are not permitted to talk to each other.  Ask yourself how likely is that all three will independently produce essentially the same fundamental design?  We’re not looking for identical results, e.g. the same lines of code, but whether they reach the conclusion to use the same primary infrastructure components, arranged in acceptable ways, manage data and information in the same logical and physical chunks, integrate with other applications with the same style and approach, be secure and reliable, etc.  In the absence of enterprise architecture, the answer is usually “not very likely”.  Designs will be based on each individual team members world view, their experience base, what they are comfortable with, what new things they are interested in pursuing, how they are influenced by others including colleagues, business-side leaders, vendors, and so on.

The next part of this “thought experiment” is to ask yourself the following questions: In your organization, are you providing enough information so that each team will, through the normal course of project execution, get “the most important things” right?  Do you know what “the most important things” are?  Are you effectively communicating them and educating/guiding the organization?

The final step is to use your findings to:

• influence content creation to make sure we address “the most important things” (because EA teams often spend disproportionate time deep-diving into narrow topics that have limited impact on the enterprise – we have always said EA should be “breadth before depth”)
• communicate to and educate the people who will have the most impact across the enterprise (because EA teams often fight fires and work exclusively on the hot projects and thus only influence narrow stakeholder communities)
• create usable, easily consumable deliverables that can be quickly located (because EA teams often create excessively detailed and lengthy deliverables instead of actionable and prescriptive content, and bury them in multiple levels of hierarchy instead of with links and/or tags in easily searchable repositories)

EA leaders that regularly contemplate the implications of questions like these tend to be more systematic in defining the work that they need to do, and are more successful in completing that work in the way that has maximum impact across the enterprise.  Furthermore, they tend to suffer from less churn and are not in “react mode” as often.  Those that are fortunate enough to be able to engage their leadership in the analyses of scenarios like these tend to get maximum support for their ongoing EA programs.

Effective EA Marketing and Communication – George Paras speaking at Western PA EA Forum

Although the word “marketing” can elicit negative thoughts in the mind of a technologist, it is a necessary consideration for any EA program in order to maximize its impact on the business and establish an environment for continued contributions.  George Paras will present on this topic and lead an interactive discussion at the November meeting of the Western Pennsylvania Enterprise Architects Forum on Monday, November the 9th in Pittsburgh. 

Some topics to be in covered include:

• Who are your customers and what do they really want?  How do they know they are getting just that?
• How do define “value delivered” and what kind of measures do you take to prove it?  How can you account for short term and longer term value areas that you deliver against?
• What is effective communication and how does this relate to the deliverables of an EA program?  What kinds of EA artifacts should you use to communicate with your customers in today’s high paced business environment?
• Different styles of communication & why this matters?

The WPEAF was created in 2002 to provide opportunities for sharing best practices around the emerging field of Enterprise Architecture.  The mission of the group is to foster the sharing of non-competitive architecture processes, concepts, and artifacts in order to support business requirements.