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.

Using MIT CISR’s Operating Model to Drive BA Design

I have recently been working with a company that is getting their enterprise business architecture effort under way very successfully. One of the most successful aspects of their effort has been leveraging the operating model concept from “Enterprise Architecture As Strategy” by Dr. Jeanne Ross and others from the MIT Center for Information Systems Research (CISR). They have used this in 3 very distinct, but very effective ways:

1) They used the concept of the Operating Model as described in the book to help business executives better understand the relationship between how they run their business and the decisions that the EA should help them make.
2) They used the Operating Model as the basis of discussion with first the executive board, and then different business leaders across the company to develop a series of models that represent a high level vision of how they currently operate, and then also as a basis for their vision of how they want to operate in the future. The result was that they operated a variety of Coordination models, but with the help and guidance of the Business Architecture Team, they came to an agreement on the need for the Unification model.
3) And finally, and probably also most impressively, they used the Operating Model graphics along with a series of relationship maps to discuss, analyze and makes decisions about which business processes should be standardized, and which processes should be integrated with what common shared information.

Given the success so far, I am sure I will be sharing more of the aspects that have contributed to their success (org structure, participation, driving motivation to name a few); but for now I will leave you with this. If you are struggling with a way to discuss meaningful change in your enterprise, leverage the MIT CISR Operating Model.

Insights on Enterprise Application Architecture

Check out my presentation below. Let me know what you think.

Directions: As with any domain of EA (business, info/data, application, technology), you must establish a view, value proposition, and advocate/sponsor to apply architecture at the enterprise level. Without that, you continue the cycle of silo-oriented decision-making, design, and solutions.

Variations on the Architecture Theme: Solutions, IT and Enterprise Architectures – IASA World Summit 2010 New York

In a Keynote Presentation at the upcoming IASA World Summit 2010, September 22-24 in New York, Tim Westbrock and George Paras will be sharing ideas and leading a discussion on the dynamics that exist between the roles of Solutions, IT, and Enterprise Architects, what they mean to your enterprise, and what they mean to practitioners and IT leaders.  We hope you can join us.

Abstract: Most organizations that claim to be practicing “enterprise” architecture are really just doing “IT” architecture (ITA), and many of those are primarily focused on “solution” architecture.  If they are all “architecture”, do the distinctions matter?  Absolutely! And all these variations of “architecture” are important.  Our research and client observations reveal that most organizations do not have clarity on how to leverage these roles or even how to set expectations and measure their contributions.  For an organization to extract the highest value from architecture, and for the practitioners to get the most satisfaction and rewards for their work, it is critical that the stakeholders understand the differences.  It is also imperative that the organization learn that all these roles must exist and that they must work together to achieve the organization’s objectives.         

Topics will include:

• The key characteristics of EA, ITA and Solutions Architect roles and practices
• Leveraging your Solutions Architecture and ITA work to move up to holistic EA – preparing yourself for your next leap
• Moving from the Traditional to the Transformational View of EA to lead true business transformation
• Getting Started with Business Architecture and Strategic Capabilities Analysis as part of EA
• Tips on what to do if your organization does not yet have an EA or ITA practice
• The personal skills required for each role, and how to move from one to another

EAdirections speaking at AOGEA Collaboration Event in Southfield, MI

George Paras and Tim Westbrock are scheduled to speak at the upcoming Collaboration Event sponsored by the AOGEA Michigan Chapter (Association of Open Group Enterprise Architects) on September 16, 2010 from 2:00 PM to 7:00 PM at Lawrence Technological University in Southfield, MI.  The theme of the event is “Interoperability between various disciplines in an enterprise”.

In our session titled, “Don’t Call It EA if It Isn’t EA!: Holistic EA for a Tightly Integrated Enterprise” we’ll be discussing the dynamics of Enterprise Architecture as it evolves from an IT-oriented discipline into a necessary part of a compelling and successful business transformation effort.

This event is a collaboration between the AOGEA Michigan Chapter and the ABPMP SE Michigan Chapter (The Association of Business Process Management), itSMF Great Lakes Chapter (Information Technology Service Management Forum), SE Michigan IIBA Chapter (International Institute of Business Analysis) and the local PMI Chapter (Project Management Institute).

Further details will be posted shortly on the AOGEA Michigan Chapter site or use the attached form to contact us for more information.

Name(required)

Email(required)

Website

Message

Market Driven Enterprise Architecture Survey

Market Orientation is a business planning discipline that stresses an understanding of market conditions and their impact on your enterprise as the major driver for operational and strategic plans. Obviously, this should then also be a major driver for EA planning. Regardless of whether you formally adopt Market Orientation in your enterprise, you will find the survey interesting, and the author (a colleague of ours, Hjalte Hojsgaard) would much appreciate your time and consideration.  It is a 10-15 minute effort.

You can access the survey by clicking here.

Thanks for your consideration.