When you want to find an answer to a problem, it is critical that you ask the right question.  This bit of advice is playing out in my life, yet again.

Every couple of months, I bump up against one of the core reasons for Enterprise Architecture to exist: to deliver a simpler, more agile, less expensive IT ecosystem.

And there’s the rub.  EA doesn’t deliver that ecosystem by itself.  EA is part of a larger system of business processes, some of which fund projects, some which generate software changes, and some which monitor systems and respond to incidents.  

So how can we effect this change?  That requires a systemic view of the problem we are trying to address.  To describe my approach, I’m sharing “Nick’s opinion” of the mission and vision needed to deliver on this goal.

The Simplified IT Vision: a simple ecosystem, with information that can be used where it lay, without the need for expensive processes to move it, translate it, and understand it.  Information that can be reached simply, on an infrastructure that is reliable and resilient to the peaks and valleys of normal, and even extraordinary, situations.  Support for the business that is more reliable than the business itself.

The Simplified IT mission: to manage the IT ecosystem, and the demands of the business on it, so that needs are quickly met, while the ecosystem itself becomes progressively simpler, more balanced and easier to manage.

To address these issues, appropriate goals must be set to:

• understand the system as it is,
• understand the factors that are driving change to it,
• remove the sources of complexity from business processes,
• insert the discipline of simplicity into the business of IT,
• track progress, report results, and systematically improve.

When creating a balanced scorecard for IT, these are some of the things that need to be understood, measured, and delivered through the practice of Enterprise Architecture.

In effect, the question is this:

How can we systematically grow a simple and well balanced information technology infrastructure?

Key words:

• “we” – As an Enterprise Architect, I take responsibility for my part, and am willing to be accountable for results.
   
• “systematically” – The effect I seek must be repeatable and scalable, built in to the processes and culture of the organization
   
• “grow” – I recognize that simplicity takes time and attention.  It does not come over night.  Simplicity must be nurtured and only through a long-term commitment to delivering it, can a simple ecosystem emerge.
   
• “simple and well balanced” – Simplicity for the sake of itself is not the goal.  The needs of IT to own the infrastructure must be balanced with the needs of business to be able to rapidly change it.  If there is complexity in technology, let that complexity fall to the people best able to make technical decisions. 
   
• “IT infrastructure” – All the talk of agile development and SOA and patterns and frameworks don’t amount to a hill of beans if, at the end, we cannot reap the benefits of what we have sown in the form of a sustaining system that is able to meet the needs of end users and business stakeholders.  We cannot stop at measuring code quality or time-to-market.  Those are good measures, but we need to go further.  We must  measure the entire system of systems: we must measure the complexity, resiliency, and reliability of IT as a whole.

Let this be the key question for Enterprise Architecture everywhere.  Let’s focus on the thing that matters and let the other stuff die out.

Alignment has effects.  What questions should you ask of yourself to insure you are aligned to a goal like this?  Here’s a list of questions to consider?

• If you are doing a project in EA, and you cannot see how it aligns to answering that question, ask yourself: are we spending time on the right thing? 
• Are your processes optimized to root out complexity and drive for simplicity?
• Are you collecting and managing information that can support the difficult decisions needed to counteract years of “not looking” at complexity as the core issue?
• Can you describe the system as it stands and describe your part in improving it, using actual measures? 
• Are your standards worded in such a way that any system that meets or exceeds standards is a system that supports this goal?

That is the power of having a goal and describing it for everyone to see.  You can push towards a vision, measure progress, and perform the necessary work to make it real.

Just a quick note.  I ran across this interesting post from Leo de Sousa, an Enterprise Architect in the Higher Education setting, who uses a Capability Maturity Model to help him to measure and drive EA maturity.

This is one of the most common ways to use measurement to improve Enterprise Architecture.  As I pointed out in my post on measurement, EA in every organization needs not only to have a balanced scorecard but also to participate in a balanced scorecard in order for the value to be measured and rewarded.  In many ways, a maturity model is a balanced scorecard.  Doing better at "maturity" means that your measurement improves.  Driving to improve that measure motivates change.

I'll blog again on this topic.  I just wanted to share Leo's excellent post.

Ah, the sweet sounds of success. 

I got the opportunity, this week, to collect a list of requirements for a strategic planning tool that we will license and use within Microsoft IT (COTS).  The fact that I got to collect requirements is not particularly cool.  What is cool is this: I made a point of using a business process model to collect them in an agile process that took less than a week to run, start to finish.

Every day, I try to find ways to make Enterprise Architecture relevant to stakeholders.  Every day, I look for reasons to trace success in our normal IT duties back to the efforts of the EA team.  In this case, it was the simple demonstration of how the requirements for a system were directly derived from the needs of a business process.

This method, for those not familiar with it, involves insuring that a process model exists for the business, in each of the areas where a particular capability needs to be developed or improved.  Now, the existence of a process model does NOT mean that the process model is detailed to the task level.  That is simply not necessary, especially when specifying requirements for a COTS tool. 

The advantage of this method is this: our requirements are far more rich, and far more complete, and developed far more quickly, than if we had simply employed 'traditional' use case analysis to derive them.  We didn't start with task-level technical functions (like "user logon," or "collect application metadata") and work up to describe the user interface steps needed to use them.  We started with the business objectives and methods (like "manage portfolio" and "quarterly funding cycle"), and quickly found the scenarios that we needed to detail.  This method is far faster, and far more resilient, than traditional use case analysis. 

The process model that I developed for this use is high level, but it covers all of the functions of IT management and Strategic Planning where we are expecting to use a tool.  The requirements are gathered, and the RFP has been released.  Once the product is selected, however, we will need a detailed model, so we will be spending some time, in the near future, to refine that high-level model and better understand the detailed processes that various constituencies will engage in.  (I'm being agile here.  I don't develop something before I need it, and only what I need to perform the task at hand).

That detailed process work begins next week. 

For now... success is demonstrating that deriving requirements from a process map works, and works well.

Oh, and we can manage it entirely in a repository-based modeling environment. 

EA works.  Q.E.D.

One thing that I've come to truly appreciate: the balanced scorecard.  Don't get me wrong: I've been using scorecards and dashboards for over a decade.  I helped to build one at American Express.  But I have come to see, from an executive level, why they are so freakin' useful... you can use them to hold people accountable to measurable strategic improvement.

With a scorecard, it is possible to reduce "passion-based decision making" from the organization, without requiring every decision to be based on Return-on-investment.  (I like ROI, but only as a single measure within a balanced scorecard, not as the entire scorecard mechanism ;-).  If everyone understands the mechanisms by which "organizational health" are measured, then it is OK to improve one measure at the expense of another if the final outcome moves toward "health." 

In that vein, I'm looking at the measures that Enterprise Architecture should use to demonstrate alignment with critical IT strategies and business goals.  We have to make sure that our work delivers value, and demonstrate that value, as part of our own scorecard. 

The Corporate Executive Board, an excellent organization that brings together peers from across industry, put together a presentation on the various measures of Enterprise Architecture used by their member companies.  I won't go into details, but it appears that the measures break down into four general areas:

• EA environment and activities -- this is what I call "Proof of Life" metrics.  Useful process metrics, and you can put ranges on them to push general activity.  These kinds of measures include "number of to-be architectures defined," and "number of business processes mapped."  Unfortunately, if a metric is not properly aligned, these metrics can end up being little more than "looking busy."  These metrics prove you are working, but not that the work is having a positive impact.
   
• EA compliance and adoption -- these are the "Proof of Effect" metrics.  This is a lot closer to proving the case that EA is not only present, and busy, but having an effect.  These include measures like "% of applications used by more than one business" and "% of projects compliant with EA standards" and "% of transactions that adhere to master data standards."  Assumably, these are good performance indicators that can be rationally tied to business value.  Having this measure is important.  Having that connection to business value is also important.  Note that the CEB study did not include two of the key measures that Microsoft IT finds important:
• % of Business Stakeholders that view IT as a trusted advisor and strategic partner, and
• % of Strategic Project Milestones reached on time 
   
• Spending and Savings -- these are the "Cost Cutting" metrics.  These are directly valuable to the business, as a single dollar of cost saved can go straight to the bottom line.  This group of measures includes things like "savings from a reduction in interfaces," and "savings from standardized purchase agreements."  You often need the "Proof of Effect" metrics to back up this group, to show that there is a correlation.  Otherwise, you can leave open the possibility of having a really large impact, for which another group is given credit.  For those of you involved in getting funding for EA, you'll recognize how perilous that road can be.
   
• Revenue and Profit -- these are the "Value Stream" metrics.  These metrics are valuable to the company's stockholders in the most visible of ways.  Metrics like these can include "revenue from new IT-enabled business capabilities" or "opportunity benefits of agility: revenue during time-to-market savings."  Unfortunately, it can be a long road between "govern the standards or an IT project" and "increase revenue."  At this level, EA can be part of a contribution to IT alignment agility and quality, which can be part of a contribution to Business agility and performance, which contributes to Business profitability.  On the other hand, I think that these numbers are not the better measure of EA performance since the contribution can vary wildly from one project to the next, or even one quarter to the next, due to conditions that are completely outside of the control of EA (or even IT).  In many cases, these measures are the "cinnamon air freshener" of the CIO's office.  They smell nice, but vanish quickly, leaving behind no evidence that they were ever there.

Personally, I found this study useful on so many fronts.  It gave me context, ideas, and key questions to answer.  But now I'd like to ask you, the practitioner... what do you think?

If it were up to you to create a measure of Enterprise Architecture, what metrics would you collect?  What metrics would you ignore? 

Please share...

Assuming that “Architecture” can be generically defined as “the art and science of designing or constructing something” (adapted from here and here), then what exactly is Business Architecture?

Extending the generalized definition above, a Business Architect should be “someone concerned with the art and science of designing and constructing a business.”  Note the verb: constructing.  A business architect needs to be able to construct a business… from parts.

Reality check: How many people, with the title of business architect, are responsible for constructing a business? 

Most present business architects are technologists, concerned primarily with the alignment of IT projects to business strategies.  They may be planners or solution owners or process owners… but most work in IT departments of large organizations, often directly with the Enterprise Architecture function.

But if we take the view that a Business Architect is responsible for designing a business, or constructing it from constituent parts, then who should have the title of Business Architect?  Should it be an IT person… or should it be a business person?

I do not believe that Business Architecture is a technical function. 

In fact, I don’t believe that IT people do a good job, at all, of describing the architecture of a business, much less making design decisions about the structure, roles, responsibilities, and coordinated artifacts that make up Business Architecture.

But if it is a business skill, what do we get by applying the architectural approach?  We know what it means to be a business person.  What does it mean to be a business architect?

Operating as a business architect requires rigorous engineering skills, an understanding of patterns, and the ability to convey complex ideas through images.  He or she must use a rigorous methodology and clear visual language for creating rich diagrams that depict the business from different perspectives.  To build out the science, we need to create a comprehensive set of cost, flexibility, durability, and agility methods associated with producing viable designs.  Using visual models, business architects can review each other’s efforts, evaluate compliance, test for quality, and to produce detailed design that form the basis of activities.

In effect, if the impact of Business Architecture is to be fully realized, I believe that Business Architecture should become a rigorous and well defined science that is taught to people in Business Schools around the world.  Every MBA would be exposed to business architecture, and some graduates would focus on the profession.

I’m interested in seeing the development of an MBA program in Business Architecture.

Does such a thing already exist?  If you know, please share…