Creating context between BPM and EA

By |2010-06-22T02:27:50+00:00June 22nd, 2010|Enterprise Architecture|

I’ve spent some time in recent weeks focusing on the touchpoints between practitioners of BPM and the core processes of Enterprise Architecture.  I’m looking for ways to improve common understanding, re-align processes, and reduce the friction that sometimes shows up when practitioners of these two different arts don’t understand one another’s goals and methods.

For the sake of this post, I will focus on customer centric aspects of BPM (also known as “Outside In” BPM).  While this is not the only way that BPM adds value, and is perhaps not even the most common way, it is a common meme in articles and blogs.  Proponents of this method can tell a strong story of value by focusing on improving customer experience.


Enterprise Architecture, as I’ve pointed out in prior posts, is focused on connecting business strategy to execution… but where do the strategies originate from?  From thin air?  Perhaps, from the latest issue of Business Week?  (If so, find another job ;-).  Strategies originate from business leaders (and their trusted advisors) reviewing and analyzing the influencers on the business, including customer opinions, to create a list of specific changes and goals that they would like to see.  More importantly, strategies reflect an implicit prioritization: of all the things that the business could focus on, the strategy represents the specific goals that executives want the business to focus on. 


Strategies are the output of a process of business assessment and competitive review, performed by the executive team.  Once the executives have considered the various influencers, and performed a review of the business model and business performance, they make key decisions that result in business strategy.  Among those list of business influencers is “customer opinion,” and they are taken into account in formulating strategy, especially where those opinions have an influence on business performance (loyalty, purchase behavior, brand value, etc). 

The key observation from this combination is that “Outside-In” BPM is really all about providing ideas for improvement, but if those ideas are not fed in to the executive pipeline, and don’t result in a formal strategy from the business, then they are not part of the focus that the business is asking for.  In other words, if an executive says “we should focus resources on creating new products,” she is not going to be happy to hear someone say “but we should focus on improving customer experience instead!”  The result of that conversation is obvious: “I’ll back that, if you don’t spend any money on it.” 

The combination of the two images above helps to illustrate how these two focus areas compare:


One conclusion that is fairly easy to draw: in order to maximize the impact of Outside-In BPM, make sure to break the effort into three parts. 

  • Step one is the analysis that determines that there exists an opportunity to impact the business by focusing on customer experience.  No improvement yet… just an estimate of costs and benefits to influence the formation of business strategy. 
  • Step two is to work with executives to insure that they take that potential impact into consideration in the formulation of strategy. 
  • If a strategy emerges that indicates that they agree, then proceed to step three and begin a formal BPM process.  Otherwise, your impact will be limited to performing BPM projects on a shoestring.

This is one place where Enterprise Architecture can help.  By working with EA, the BPM professional can get the input they need to “position” the benefits of the customer-focused proposal to the business leader who has to balance the resources and benefits to serve the needs of the shareholders.

Design for Business Agility: Can Mathematical Models be developed?

By |2010-06-17T01:43:00+00:00June 17th, 2010|Enterprise Architecture|

Sometimes, if you multi-task two different activities, your mind finds connections between them that would not be otherwise obvious.  I’m listening to a podcast on Design for Six Sigma and Design for Innovation in Manufacturing.  At the same time, I’m writing out e-mail on an integrated systems design that I’m working through with my internal organization.

So what occurs to me?  There are about a dozen different possible system designs that I could consider. I have built one design, but how do I know that it is right?  I can use principles and practices, but in reality, those principles are based on the experiences of other people, not science or math.  Just empirical observation.  My principles are based on good guesswork.

In a manufacturing environment, I could create a mathematical model, in software, that shows how changes to processes would impact the speed and quality of manufactured products.  I can consider different designs, and then introduce disruptive events, and watch the results.  But I cannot really do that in a software system design.

Here’s what I want to do.

I want to model a set of software services, with responsibilities and message composition built up, in a reasonable model of a solution.  I’d like to create four or five different models of the same solution, using different services (different responsibilities, different message composition).  Then I’d like to turn on simulation of each model to make sure that it performs reasonably well.  I can tell you now that all of these designs will probably work.

Then I want to introduce disruptive events like business change. I’d like to know which system designs are most able to stand up to changes in business strategies.  That means, which system designs will necessitate patterns of deployment behavior that creates an obstacle to agility.

In other words: Which designs, once implemented, drive people to make slow changes when fast changes are needed?

Principles and Patterns are based on experience.  That’s great.  But science and math should be considered as well.  Any ideas?

Inserting Architectural Governance into the IT Program Funding Cycle

By |2010-06-15T08:50:52+00:00June 15th, 2010|Enterprise Architecture|

People do what you pay them to do.  That much is clear.  In most businesses, if you pay (reward, incentive) your employees for performing a particular task, then the task will be performed.  Also in most businesses, people are busy, so if you don’t pay them to perform a particular task, it largely won’t be performed.

So in organizations where there is little or no tradition of governance, and where many people openly oppose the notion of having another person or team “telling them what to do,” how do you get people to sign up, show up, and put up?  You pay them.

I’m not talking about bonuses, and I’m not talking about personal rewards.  When dealing with the governance of projects within a business, I’m talking about requiring them to justify hours spent against a budget, and then creating controls that create and distribute the funds for that budget. 

A large number of IT shops use this mechanism for basic governance.

A primer…

Let’s say you have five project teams.  They all want to perform different projects based on what the business wants (or, as is often the case in IT, based on what IT believes that the business needs).  But there is no way that all of those projects can actually be completed in the coming year.  You can use priority to decide what to do, or you can use teams of architects to drill in to the project teams and determine what features will be built, and by whom.  But that doesn’t mean that the decisions made in advance will be followed.  Just because business leaders don’t want that ESB, does that mean that the developers won’t build it?

The rigor needed is to require project managers (and in some organizations, the project team members themselves) to “book” their time against a budget that has been set aside to fund their project.  So team one, that wants to build features A, B, and C, starts with an estimate the costs of that effort.  The architects and planners decide that team one should only build features A and B.  So they budget only enough money to build A and B.  Assuming that people are actually pulled off of projects when the money runs out, then project teams will have a built-in incentive to either deliver what they promise, or inflate their estimates so that the amount requested covers all of the desired scope, regardless of the executive decisions.

Now, in this environment, how do you add architectural governance?  Add architecture to the funding model, of course.

When a project is being considered for funding, take a look at specific attributes of the project.  If it is important, large, risky, or likely to need oversight, then it should follow specific rules for architectural governance.  (The rest of the projects, which will account for a large majority of the budget, do not require architectural governance, and can simply negotiate directly with their business stakeholders on the basis of ROI).

This subset of projects needs special governance, architectural governance.  That means that specific requirements are placed on the project as it is being conceived.  In fact, you may need a two-stage process just to get the project started: stage one to get the information in place to decide whether to do it, and stage two to perform the actual project, with a funding decision taking place in the middle.

The key requirements for deciding if a project should be performed will go far beyond the normal ROI calculation.  Large, risky, or potentially game-changing projects need to have architects fully engaged to help set the scope of the project, decide what enterprise assets will be improved or addressed, and focus in on stability, scalability, security, agility, and performance.  Information has to be collected about the components in other systems that need to be improved, so that careful dependencies can be taken.  Roadmaps need to be lined up because success may depend on many projects producing changes in many systems.

The flexibility that the business will have in “compressing the scope to reduce the budget” will be severely curtailed.  The ROI calculation will not be quite as flexible, as there will be a great deal of cost that the business cannot squeeze out. 

A team of architects needs to oversee this information gathering process, and needs to be present to defend the costs when the business tries to compress the budget or take short-sighted cuts.  The project needs to deliver value frequently, all the way to the customer, in a rhythm that increases confidence in the IT organization to succeed.  Only if all of these criteria are planned in, and carefully described, can the project get through the funding process and begin effort.

All the architectural review in the world can’t begin to provide the value that architectural governance during the funding cycle provides. 

Sometimes, to win the game, you have to be at the right starting line…

Improving how you measure the maturity of a business capability

By |2010-06-12T01:10:07+00:00June 12th, 2010|Enterprise Architecture|

Depending on the level of maturity of your Business Architecture practice, there are many different methods to measure the maturity of a business capability.  In fact, the method that you use for measurement will depend entirely on your own level of BA maturity.  The better supported your BA program is, the more accurate you will be in measuring the maturity of the business capabilities in question.

Why measure business capability maturity

For those readers who don’t know what I’m talking about, here’s a primer.

In order to insure alignment, Business Architects will take the strategies of the business and analyze them.  They will create measurable goals out of those strategy statements in order to determine the relative value of each, and then map those goals to a standard taxonomy of capabilities.  That tells you which capabilities are needed.  It doesn’t tell you where investment is needed. 

The reality is that you can’t invest in everything, nor should you.  You should invest in capabilities that are needed by the strategy but which are the weakest.  An improvement in a weak capability can make a strategy possible. 

So how do you know which capabilities are the weakest?  You measure the maturity of those business capabilities. 

Methods of Measurement

As I mentioned before, there are different for measuring the maturity of a business capability.  Which method you use depends on the level of trust and engagement that your business architecture program has. 

  Maturity Level 1 Maturity Level 2 Maturity Level 3 Maturity Level 4
Level of Business Engagement Business contacts do not buy in to the value of business architecture, or BAs have no direct business contacts Business contacts are willing to work with a BA, but don’t want to spend any effort to make their BA successful Business contacts collaborate with Business Architecture to assist with the chartering of initiatives. Business contacts rely on Business Architecture to assess influencers, review the model, and create new strategies.
Source of information Observation of the behavior of the business.  Look at the initiatives that they charter as an indication of strategy, and importance. Business contacts share their strategy memos and actively work to review, refine, and leverage the goals. Business takes feedback about how well their investments align. Business Architects are included in conversations about business opportunities and are consulted in the formation of business initiatives to meet strategic goals. Business Architects are engaged in customer contacts and business assessments.  They work with senior executives to create strategies based on business model capability alignment.
Method of Measurement Indirect or occasional interviews of business stakeholders to survey the perceived importance and maturity of some capabilities.  Direct interviews with business stakeholders asking about the capabilities that are mapped to strategy.  Subjective survey of performance, maturity, and importance.  Importance is determined by the relative value of the goals that a capability is mapped to.  Performance is determined by metrics.  Maturity reflects measures of underlying tools, processes, information and role clarity. Additional attributes of measurement are added to illustrate the level of alignment to specific business models and the relative value of each model to the present goals and vision of the enterprise.
Flaws that will drive you to the next level Very sparse information gathering, no goal maps, capability heat maps are tentative at best.  Not worth sharing. Interviews are useful, but subjective.  The relative importance of different capabilities cannot be determined using this method. Limited set of measures, and doesn’t reflect the merit of a capability with respect to the business models that may most directly reflect the enterprise’s future.  



Look across the “source of information” and “Method of Measurement” rows, and see if you can find the method that you currently use to measure the maturity of your capabilities.  That is the best indicator of the level of maturity that you are at.  Look at the column describing that level of maturity.  Now, look to the right and see if you can discern the changes that you would need to make in the maturity of your BA practice in order to move to the next level of Business Architecture maturity.

The method that you use to measure the maturity of business capabilities is directly reflective of the maturity of your own business architecture practice.  It is necessary to make the move to the next level of maturity in measurement if you wish to move to the next level of BA practice maturity.

It has value… but do you need it?

By |2010-06-09T11:06:00+00:00June 9th, 2010|Enterprise Architecture|

Recently, Chris Potts threw this nugget out on Twitter:


Instead of ‘demand-managing’ to fit an arbitrary IT budget, challenge whether your strategy needs the value an investment is promising

What a terrific comment and one that really hits home with me.  As we look to create “alignment” by showing “traceability” in Enterprise Architecture, the process models and practices that so often show up in frameworks go on and on about “demonstrating that an activity can be traced to a strategy.”  However, there is nearly no talk about what happens next… showing that the value produced by an activity is actually necessary to make the strategy come to life!

A number of years ago, I worked at a financial institution.  They were a large company, and had a fairly relaxed dress code… except my department.  I worked for one of the hundreds of Vice Presidents and his team was required to wear nice suits to work every day.  Now, I have nothing wrong with wearing a suit.  But this was in South Florida, and wearing a lot of clothing has its drawbacks, especially in the afternoon when the sun was high in the sky. 

But I followed the rules and bought suits… many of them.  Now, I could have purchased cheap suits, but my manager had a keen eye for fashion and he would not have been happy to let me make presentations to senior executives if I was not well dressed.  On the other hand, I could have bought really expensive designer suits for $1,000 or more each.  I would have looked good, for sure, but I would not have seen a positive impact on my career.

I went with nice, well tailored suits… that looked good but were not so expensive that I’d be going into debt to buy them.  $400 or so for each one.  My career was stable and my manager was happy.

If I take that metaphor and apply it to IT planning: we often find ourselves with a project that represents a $1,000 suit.  It is expensive, yet delivers moderate value.  So if I already have a closet full of $400 suits, do I buy it?  No.  Now, what if I don’t have a closet full of suits.  I need one… but do I need a $1,000 suit?  No.  I’ll cut the costs down, trimming scope and resources.

In every case, that $1,000 suit was directly traceable to my strategy (“comply with business expectations, and grow my career visibility”), but in both cases, I did not buy it. 

Chris Potts’ observation was excellent and well worth understanding.  Alignment, alone, will not insure that IT delivers value.  It is not just about delivering value.  It is about delivering the right level of value, sufficient to bring the strategy to life, without incurring unnecessary costs. 

Now… to apply this thinking to business intelligence… hmmm… 🙂

What process gives a tool to a fool?

By |2010-06-08T16:50:41+00:00June 8th, 2010|Enterprise Architecture|

Mike Walker recently blogged about the veracity of architectural models, and the precautions that should be taken to insure that an architectural model is actually accurate and correct before it is used to make decisions.  (see A fool with a tool is still a fool).  Mike points out some very good points about how the architect using the model should be certain of its accuracy before making decisions on the basis of it.

I would add, however, that there is a deeper problem, and one that Mike did not address.  Why does the organization trust the architect to make decisions on the basis of a model?

That is not to say that a model cannot be useful.  It certainly can be useful for illustrating intention and for capturing information in a manner that is readily usable for other purposes.  However, there are two kinds of decisions that can be influenced by a model: technical decisions and portfolio decisions.  Technical decisions answer the question “does this model reflect a good way to solve this problem?” Portfolio decisions answer the question “if not, what are we going to do about it?”

Who is responsible for these decisions?

Technical: I have no problem with an architect making a recommendation to an empowered development team or group, on the basis of a model, that a particular aspect of their work should change.  However, even for that technical decision, I’d wonder about any team that didn’t invest, in the dev team itself, the right to challenge that decision.  An empowered dev team will question any architectural decision that appears dumb.  (They will challenge the smart decisions, too, but that’s another point).  If, during that challenge, the architect produces the model, the dev team can say “but the model is wrong.”  At that point, the discussion and correction of the model may result in a change in the advice itself.  The system is self correcting, as long as the architect is working with an empowered development team.

Portfolio: no architect should be responsible for making portfolio decisions.  They may be accountable for making recommendations, but at the end of the day, there should be some governance or steering committee of business leaders (or a single business leader) who is accountable for spending money.  That person is nearly never the architect.  If that person is the architect, then the process is broken, because the architect is a poor choice for managing the portfolio.  There’s an inherent conflict of interest in that situation. 

So, if the process requires the architect to manage the portfolio, then the process will inevitably make a fool out of any architect.  In that case, don’t fix the model… fix the process.

But back to Mike’s concern: what if we make a bad portfolio decision on the basis of a bad architectural model?  Well, sure, we don’t want to do that.  But the alternative is not to drop the concept of modeling.  That would be equivalent to saying “missing data” is better than data that is “90% accurate.”  As Mike correctly points out, “all models are wrong… but some models are useful.”  We need to figure out how accurate a model must be in order to actually be useful.

Making architectural decisions without architectural models is driving a fast car with our eyes closed.  Making architectural decisions with inaccurate models is driving the same car in a heavy rainstorm. 

I’ll take the latter every time.