On the federated ownership of a conceptual domain

By |2009-01-22T10:27:00+00:00January 22nd, 2009|Enterprise Architecture|

As I mentioned in my last post, we have produced an interesting conceptual model of IT as a business, from Business Motivation all the way through to Operations.  For those of you who know I’m a SOA promoter: yes, I can represent a composite application in the repository.

More importantly, I can represent the reasons that a system exists, the metrics that demonstrate it’s value, the business rules that must be enforced, the business processes that take place, the people and organization hierarchy of the business, the programs and projects that drive change, the systems that deliver processing, security, and infrastructure services, and the operations that keep the lights on.

Microsoft IT is a big place (and apparently getting a little smaller, alas).  So it is not possible for one team to “own” a model of this breadth without aligning with other sizable groups or divisions.  There is no way to represent “one view of the truth” without creating a sense of shared ownership.

On the other hand, the motivations of each team can be different, and their perspectives on the model can be different as well.  When creating a shared model, compromises must be made in order to get to a solution that actually works: rational, minimal, consistent, and aligned to the business. 

With shared ownership, each compromise has to be carefully documented and signed off, because without that careful documentation, and the organizational will-power to refer to it, every compromise will be visited, and revisited, over and over ad nauseum.  The noisy person and the politically well connected person will “earn” compromises in the model that challenge it’s quality and reduce its effectiveness. 

On the other hand, as organizations change and adopt new ideas and well-organized principles, the model must change as well.  We saw SOA add a different understanding of software applications and shared resources.  We saw ITIL and MOF add a different approach to managing IT operations as services.  Every year, something must change, even if it is just a little bit.  Federated ownership is an excellent way to insure that those changes can be captured and incorporated.

But is federated ownership the only way?  Of that, I’m not certain.  If I look to the legal system, there is the body of law that has emerged through legislation, case law, and regulation that makes for a complex but workable system of rules and adjudications.  There is no “owner” for all laws dealing with small businesses, for example. 

In addition, if ownership is federated, what does that really mean?  How does the central model stay consistent and useful when large subsections can change independently? 

We have tried to create a central model that is minimal, that has only core objects and maintains only core relationships, so we can be immune from some obvious changes.  On the other hand, this is an imperfect science.  There is no way to be insulated from change. 

Still mulling ownership structures.  If anyone has any comments or advice, please share. 

Ship It!

By |2009-01-16T09:29:00+00:00January 16th, 2009|Enterprise Architecture|

It’s been a while since I was blogging regularly.  The reason: I was in a ship cycle.  As we approached our deadline for delivery of a comprehensive end-to-end information model for information technology, more and more of my time was spent focusing on the details. 

Is it explained well enough?  Are all of the connections correct?  Have I captured all of the reviewers’ feedback? 

In the end, the MS IT Common Conceptual Model is a set of domain models, all integrated with one another:

  • Business Motivation
  • Business Architecture and IT Alignment
  • Business Program Management
  • Business Process Management
  • IT Project Management
  • Service Level Management
  • Analysis and Requirements Management (incl. Traceability)
  • IT Software Development and Testing
  • IT Software Deployment (Service Transition)
  • Application Monitoring and Mitigation
  • Operational Traceability and Notification

It has taken over a year of hard work, first by Bob Sturm to lay the groundwork and then by myself to roll the model to an initial version, to get to this date.  Whew! 

I’m sure I’ll still be involved with this, and I may end up writing a book about it, but for the most part, I’m done!

We shipped.  On to the next thing…

An examination of the OMG Business Motivation Model

By |2009-01-09T21:15:04+00:00January 9th, 2009|Enterprise Architecture|

Contrary to popular belief, Microsoft loves standards.  We don’t always play well with standards bodies, but it doesn’t mean that, operationally, we don’t benefit as much as the next guy from standards.  From an IT perspective, we cannot be efficient or effective without leveraging the work done by the OMG, Oasis, and other standards bodies.  In my current assignment, I am working on a cross-the-board IT metamodel, and I’ve been asked, in no uncertain terms, to clearly adopt standards where I can.

So I was heartened to see that the OMG had gone to the effort to define a business motivation model (link).  A business motivation model is a description of the data elements that go into describing a business plan.  In other words, if you had to explain why a company exists, and how it plans to make money, what bits of information would you collect?  The business motivation model answers that question.

I would love to adopt their model, so I took a deep dive into the OMG Business Motivation model.  This post is about some of the things I found re, and why I haven’t yet adopted it.

Background on the OMG BMM

I’m no historian, so I won’t go into the details of the project and why it was formed.  I would like to caution the reader about a few aspects of the final product, however.  There are some things to keep in mind when discussing the OMG BMM.  From their 1.0 spec:

The Business Motivation Model is simple. Most of its concepts have only basic attributes – identifier, text description (plus capabilities for traceability, including change date & author). Most of its associations are unconstrained: optional and many-to-many.

Software tools that support the Business Motivation Model usually provide simple recording and reporting functionality, with some analysis capabilities – e.g. reporting of objectives that are not quantified, business rules that are not derived from any business policy.

The Business Motivation Model is not:

  • A specification for a business development management process or tool
  • A specification for a project definition or management process or tool
  • A specification for a full business model.

The purpose of the BMM is succinctly described in the following excerpt from the spec.

The basic idea is to develop a business model for the elements of the business plans before system design or technical development is begun. In this manner, the business plans can become the foundation for such activity, connecting system solutions firmly to their business intent.

In other words, the BMM is the cornerstone of alignment.  Alignment is a key part of the Enterprise Architecture mission.  Any enterprise architect needs to be able to describe, and understand, some kind of business motivation model in order to describe, for their organization, why they believe that the investments of IT are aligned to the goals of the business. 

(For details on the three business functions of Enterprise Architecture, follow up here and here).

For reference, and to make the rest of the discussion easier to follow, I have attached the graphic from the Business Motivation Model below.  If you would like to see it full size, click on the image.

OMG Business motivation model

First off, let me say that the team that put together the OMG BMM did a fine job.  What is there is excellent, and far better than ‘starting from scratch’.  My comments are not criticism, but suggestions for improvement. 

First concern: bizarre assumptions

I started by reading the specification, stopping every few pages on one bizarre assumption after another.  For a specification that attempts to be agnostic to methodology, they are certainly tainted by a set of experiences that are selective and somewhat arbitrary.  Note that the model itself doesn’t make most these mistakes… just the explanatory text.  Good examples:

Ref BMM Quote Comment
Section 7.2.3 – Key Ideas in the BMM

“A fundamental assumption of the Business Motivation Model is that what an enterprise does is driven not by change, but by how the enterprise decides to react to change.” (OMG BMM)

Influencers include internal leaders, some of whom will instigate change.  Statements like this assume those leaders are on the Outside.  Extending this statement: Steve Jobs does not work with Apple employees to change the market, but rather Apple reacts to Steve Jobs!  Wow!  Better not tell Apple that!
Section 7.2.2 – Motivation

“Goals are defined because people in authority in the enterprise:
• Assess the effect of some influences on the enterprise
• Decide what the goals should be.” (OMG BMM)

Statements like this are breathtaking in their inaccuracy.  Are these “people in authority” influencers in their own right?  Does the vision of the enterprise influence an influencer?  Both possibilities are excluded by statements like this. 


Second concern: The choice of SWOT

The Business Motivation Model team uses, as a metaphor, the concept of a SWOT analysis, to explain why they created four high level objects: ends, means, influencers and assessments.  For those unfamiliar with this practice, the idea is to apply a SWOT analysis to a line of business to express, in a single ‘view’ all of the strengths, weaknesses, opportunities, and threats (acronym: SWOT) to that line of business. In effect, it is a report composed of four ‘sub-assessments’ and it is used to stimulate creative thinking. 

SWOT is a useful tool in business planning, but not a very powerful one and certainly not the only one.  However, the BMM team seems to have made two mistakes: 1. to pla
ce SWOT on a special pedestal, orienting the entire model around it, and 2. to generalize all assessments as reactions to influencers, and leaving out alignment assessments altogether.

The first error is egregious, but understandable.  If all you have ever seen of carpentry is a nail, you will invent a good hammer.  Unfortunately, SWOT analysis is hit-and-miss when it comes to evaluating the drivers of customer behavior, internally driven trends, investment conditions, and demonstrated practices from competitors or other industries.  It is a weak tool at best, and a poor metaphor for assessing the business environment. 

Unfortunately, the framers of this spec go beyond using SWOT to explain the BMM.  It appears, from an outsider’s point of view, that they used SWOT as the initial metaphor on which to base the structure of the model itself.  Building BMM on SWOT is like building your house on sand.

To back up this statement, I cite the following from the BMM Overview (section 7):

“the business needs to take into account the numerous Influencers that can hinder or assist its operation. These Influencers provide Opportunities that would help the enterprise operate, as well as Threats that would thwart it. Influencers also represent Strengths from within that the enterprise could exploit, or Weaknesses that it should compensate for.”

If the first error is to use SWOT, the second is to generalize all influencers as neutral entities, while excluding the goals, mission, vision, strategies, etc, as influencers in their own right. 

Good leaders do more than create goals for a company… they follow them.  This is important.  A leader both creates a goal, and then follows it.  Ever heard of “plan or work, then work your plan?”  Heck, even the seven habits go into this space.

The goal influences the people who make the plans.  The Business Motivation Model has no way of recognizing this relationship.  A plan derives from a plan, without any people being involved.  This leads directly to the next concern.

Third concern: Incompleteness for large enterprises

While the BMM authors suggest that the model can be used at any level of an organization, stating explicitly that one organization can have many business motivation models, they offer no way to connect multiple models together.  However, for most large enterprises, the real opportunities for improvement are in the spaces between the organizational units: in the cross-unit business processes where sharing could provide efficiency, effectiveness, and opportunities for customer delight, yet often go unseen by the executives who live within their business model.  (Don’t believe me?  Read Rummler and Brache).

The BMM, as currently described provides no recognition of this reality by providing no way to link multiple business models together, and thus misses the ability to describe the motivation behind many of the process or capability driven business improvement exercises that are in use today.  Without the ability to represent a business model as a motivator of business unit behavior, and the BMM as a decomposition of motivation, with respect to the fact that organizations have many business models, the BMM is a toothless lion.  Lots of growl, but no real bite.

A suggested next step

It is a good idea to adopt standards, when they are appropriate and useful.  For me, at least, many of the elements of the OMG BMM are useful, like the definitions of vision, mission, strategy and tactic.  Good stuff there.   It is the relationships between terms that I have a problem with.

I don’t have a fully-baked “Nick’s Solid Gold Model” to suggest as an alternative.  What I am going to suggest is an approach. 

Now that a high level set of elements have made their way into the public domain, well documented and well described, I suggest that the same members who created the BMM spec solicit input from end users: organizations that are seeking to actually use the model (not vendors writing software that adopts the model). 

Of the voting members on the spec committee, the overwhelming majority worked for vendors or consulting firms.  It is time to get a little reality into the picture.  End users are important.  We are solving actual business problems.  Our motivations are practical, individual, and long-lived.  We don’t just create a model, we live with it (something that consultants nearly never do).  

Go gather input.  Then update the model to address a more finely tuned understanding, and release a 2.0 version of the BMM specification.

Perhaps, then, I will be able to adopt it.