/Tag: BPM

Explaining Capability Modeling to Business Process Professionals

By |2011-08-19T11:53:05+00:00August 19th, 2011|Enterprise Architecture|

As I’ve noted in prior posts, many hard working business process management professionals find the concept of “Business Capabilities” to be confusing at best, and counterproductive at worst.  In a recent article in BPTrends, Paul Harmon made the following statement:

the idea of "capabilities" is introducing confusion into the marketplace. It is hard enough to work with an organization to create a business process architecture that can be used to effectively organize the management and measurement of how well the organization is achieving its goals. To introduce the idea that an organization should first or simultaneously create a map or hierarchy of "capabilities" and then create another hierarchy of processes is to add confusion to an already very difficult and complex task.

This confusion is well known to me.  Within Microsoft, we have a very strong group of senior professionals who base their efforts and practices on BPM concepts.  This includes Kaplan and Norton’s Balanced Scorecards, as well as methods like Six Sigma, Lean manufacturing, and Total Quality Management. 

BPM is my world too.  As readers of my blog know, I am fortunate enough to consider myself to be a follower of these same ideas, having been exposed to TQM while I was working at IBM almost 20 years ago.  I’ve worked at many levels of process improvement. 

  • At the business level: I’ve worked to convey the need for process improvement and help the stakeholders feel comfortable with methods,
  • At the modeler level: I’ve worked to collect the ideas of stakeholders and map out both current state and future state,
  • At the analysis level: I’ve worked to take models and analyze them for opportunities, target waste, and develop innovative alternatives, and
  • At the technical level: I’ve implemented a number of BPM systems and even wrote one of my own. 

 

That experience lets me have a good relationship with both my EA peers and my BPM peers.  I’m aware of both approaches, having done both.  As my readers may also know, I use business capability models in my daily work.  I create models of capabilities that are useful, valuable, and understandable.   I know the value of capability modeling.

When I talk about business capabilities with my peers, I have to be careful.  Business capabilities are poorly explained and poorly socialized.  It can be tough to convince a BPM professional to listen to these “radical” ideas when we, the community of architects and analysts who also use business capabilities, have communicated so inconsistently about them.

First off, let’s look at the environment we work in.

Business process management practices and techniques are widely used.  In many cases, they have produces very valuable results.  However, the field is still quite young.  As in any young field, there are failures as well as successes.  I’ve seen projects succeed, and been quite proud of them.  I’ve also seen projects attempt to use BPM practices, waste time and money, and produce no real result.  The team would usually deliver something, but often that delivery occurred in spite of the process efforts, and not because of them.  Like any tool, using it well produces good results, and using it poorly… doesn’t. 

Let’s start with a problem

We all have to solve business problems.  Sometimes, you need to approach a problem one way… and sometimes a different approach is called for.  Business process modeling is a powerful tool.  Business capabilities provide an additional tool.  Sometimes you need to use them. 

Let’s look at one of those times.

Joe Freeflier is a business manager in the finance group of his large company.  The company has five divisions, each with completely different business models.  The divisions operate quite independently of one another.  They don’t share the same sales force, and they don’t really speak with the same customers.  Each division has its own plants, and its own workforce.  Joe, unfortunately, works for corporate.

You see, Joe is responsible for maintaining a set of business controls, as well as insuring that each division’s revenue recognition systems and processes are compliant and auditable.  He can see how the transactions appear on the general ledger, but he also has to make sure that some basic rules are followed in order to insure that the company is behaving in a legal and responsible manner. 

Joe has a couple of teams.  One team is focused on a large merger that the company went through in January.  His team is working with this new business to merge their financial systems with one of the existing divisions.  Another team produces important reports for the senior staff, some of which feed the quarterly corporate reporting required of publically traded companies.  A third team performs spot audits and works with the divisional finance leads to insure smooth reporting all up.  Joe’s customers are really the divisions themselves… and each of those divisions have their own business processes.

Joe needs some help.  The new merger has caused some churn.  His team is having a hard time working with the new business unit, and his manager has told him not to “govern them out of business.”  Now, Joe meets every month with Jürgen, his contact from IT, and at one of those meetings, Joe vents about his current problem.  Jürgen suggests that Joe speak with his business architect Sally, and a meeting is arranged.

Sally spends some time working with Joe to understand his concerns, and now has two choices. She can suggest either a process-centric approach or a capability centric approach.  Sally does not know if the problem can be fixed with a business process change.  She doesn’t know if the tools need to change, or the policies need to change, or the information collected needs to change, or if it is a training problem.  She just knows that Joe needs help.  Let’s walk through her thinking:

Process centric:

Sally knows Joe’s business goals and the controls he needs to insure.  She proceeds to spend time with each of Joe’s divisional customers to map out their business processes, making sure that she is fairly accurate yet high level.  Three of the divisional teams have never mapped out their processes, but one has.  She starts there, and the process looks like a standard she is familiar with.  Unfortunately after interviewing some of the staff in that division, it is clear that they don’t actually follow that particular process.  So she falls back to a standard definition from an industry group, and spends a couple of meetings getting everyone to the same very-high-level process model.   Ten weeks have gone by, but she’s made some progress in understanding the landscape. 

Now, Sally visits the newly merged team and spends some serious time understanding what their existing process is, and how it may be different.  She finds that their business is based on a kind of “consignment” financing mechanism, and the revenue recognition processes that Joe uses have to be able to handle a number of new business events that he never dealt with before.  So she returns to speak with Joe about tracking these new events, and trying to fit the new financing mechanism into his controls.  Joe puts two of his team onto a small
project to craft an alternative set of controls, while the IT team begins to look at new data pathways needed in their financial system.  As it turns out, Joe doesn’t need to change his processes… what he needs is to change the way information is collected to adapt to new processes.  Joe creates his controls, and creates a set of IT requirements for the IT team to fulfill.  Sally is done.

Sally was successful, and her effort took about four months to do.  Along the way, she learned a great deal about the financial processes, and four divisional leaders now have a process model for their work.  Remember that three didn’t feel the need to create one before, and the fourth didn’t use their model.  Six months later, none of them refer to the process model at all, and it has become “shelfware.”

Capability centric:

Sally knows Joe’s business goals and the controls he needs to insure.  She spends a few days working intensively with Joe.  She has a capability taxonomy that she brought with her from another project.  Her first goal is to get a small list of capabilities that Joe sees as valuable.  After about three or four days, she has a list of capabilities that his team needs to perform in their duties.  These capabilities are “bits of process” that his team owns and needs to do consistently, regardless of the higher-level processes that his customers use.  They are the “standard parts” of processes that his customers have taken a dependency on him to perform well. 

Now, Sally visits the newly merged team and spends some time understanding what their overall process is.  Note: Sally is looking at their process!  She looks to see whether the new unit would benefit from Joe’s finance team and looks for ways to plug Joe in.  It becomes immediately apparent that Joe has some expectations that won’t fit their business.  The new business is based on a kind of “consignment” financing mechanism, and Joe is assuming a more traditional supplier-retailer business relationship.  So Sally comes back to Joe and asks him for details about his assumed business processes.  She works with Joe for another week, charting out a narrow slice of business processes from Joe’s point of view.  She then goes back to the new unit and maps out the same narrow space on a process model.

She presents these two process maps to Joe, who now understands the problem.  Joe puts two of his team onto a small project to craft an alternative set of controls, while the IT team begins to look at new data pathways needed in their financial system. 

Both methods got to the same result.

The capability effort got us there much faster.  Using business capabilities to identify the problem, and narrow the focus of the team, Joe was able to get his team to solve the problem within about four weeks of Sally’s arrival.  She didn’t have to meet with the divisional leaders even once, and she didn’t produce an all-up process model.  Had she stuck with the process-based approach, it would have take three times that long.  Along the way, the process approach produced an interesting model, but it was not later used by anyone. 

Note that, according to Lean manufacturing, the intentional creation of an output that is not actually used by anyone, is waste.  The use of capabilities allowed Sally to remove the wasteful act of creating a high-level process model. 

What I did not do

I did not answer the question: “what is a capability?”  It was not my goal, in this post, to answer that question.  My goal is to show my friends that a tool produced a good result.  If my friends want to use the tool, defining it is unnecessary.  If my friends don’t want to use the tool, defining it won’t matter.

Did you learn what a hammer was by having someone define it to you, or by swinging at a couple of nails? 

Was this a contrived example?

It was an example derived from experience.  That said, there are equally compelling examples where using the word “business capability” generates confusion.  If Sally had gone to the new business unit and had said “I know you look at things as end-to-end processes, but I want to introduce you to the concept of business capabilities,” then she would have failed in her job as a business architect.  Sally could no more use capabilities with the new business unit than she could have taught a teenager to drive by teaching him how to overhaul the transmission. 

Capabilities are a complexity.  Some business stakeholders live at that level of complexity already, and they WANT to work at that level.  For them, capabilities make sense.  Other business stakeholders live at the highest levels of end-to-end experiences.  For them, capabilities make no sense at all.

Our own worst enemy: BPM pros tell horror stories about working with EA

By |2010-07-06T21:15:25+00:00July 6th, 2010|Enterprise Architecture|

I recently asked two questions on LinkedIn.  I asked BPM professionals what they thought about working with Enterprise Architects, and I asked EA folks what they thought of working with Business Process Managers.  The results: BPM professionals want to work with you, but you have to meet them half way.

The number one complaint against Enterprise Architects?  Focusing on technology instead of business. 

Kenneth Beard of South Africa tells of Enterprise Architects who “think that EA = ITEA and BPM = name of a software … tend to live in silos, fight turf wars amongst the technical population, and are often at odds with the business they should serve, making it difficult to work with them.”

John Segal of New Zealand says

“in my experience the majority of so called EA’s are IT focused and hired to be so. Consequently they are typically interested in the automated solution aspects of BPM rather than what is to my mind its primary importance as a process design and improvement meta process.”  He goes on, “So, with IT oriented EAs emphasizing a technology solution led concept of BPM, they can effectively become an impediment to deploying BPM as a core business meta process.”

If John feels that the majority of EAs are an “impediment,” then we may have only ourselves to blame.  After all, many of the responders were Enterprise Architects, and surprisingly, they agreed.  Adrian Gregoriu of the UK shares this bit of insight:

“BPM and other process improvement efforts like Six/Lean Sigma, business process and organization alignment to strategy are left out of the definition of EA and business architecture development. In my work, I have collaborated with BPM people and efforts but could not ever engage EA people to work with them. After all, contrary to what many claim, EA seems to be mostly about IT, unfortunately.”

Alas, all is not lost.  There were also stories of success, when conditions were right. 

Kenneth Beard shared a positive opinion as well.  He prefers to work with Enterprise Architects who “understand that real EA is a set of layers for process, information, application and technology that are inseparable and work in concert & must be managed as such.”  In this environment, Mr. Beard finds that Enterprise Architects view BPM in its proper role, “BPM is seen as a customer focused initiative to improve the performance of the real enterprise architecture” and he finds these architects to be “strategic level thinkers who share an integrated view and are a pleasure to work with, and they get results.”

Alexander Samarin of Switzerland tells the story of carefully, over time, educating a team of Enterprise Architects so that they can understand how best to use BPM in their work.

“At first, I explained to the team how BPM can solve many of typical IT problems (rescuing a couple rotten projects helped me a lot). Then, in each opportunity — a difficult problem, new enterprise-wide project, developing principles, writing procedures, etc. — we applied the power of BPM (discipline, tools and practice). We gave seminars, built demos, shared our knowledge, etc.  After about 2,5 years, the first BPM-centric solution has been selected (via a tender) for the new information system of a governmental service. “

There is a great deal of insight here.  Clearly, the combination of Enterprise Architecture and Business Process Management is valuable, when it is applied right.  Clearly, Enterprise Architects are, as a group, missing out on that value.  Some folks are taking the time to educate, while others wait patiently for an EA who actually has a clue. 

There are surprising synergies.  Here is Kenneth Beard again, sharing his opinion about how important an EA repository is. 

“we need to appreciate that business leaders with different experience find it hard to grasp. Most believe it is simply too complex to document and maintain the information assets. But the diversity of each layer of the EA plus the know-how of how they work in concert is vast, and is exactly the reason why this knowledge needs to be managed in an integrated repository, with strict configuration management and change control procedures. Otherwise it remains in the heads of various SME’s and at best partly documented in numerous unrelated formats that decay with time or are lost when people move. The benefits of having it in one home are vast, enabling enterprise performance management, despite having a massive knowledge asset.”

Lastly, our friends in the BPM community have some advice on how to work well with them… focus on the customer!

Kenneth Beard tells us that “the emphasis should be on the customer experience so successful outcomes translate into meaningful results along with value for the business.”  John Macdonald of the Netherlands provides similar advice, “the intended customer experience should be the start point, then assemble the parties and methodologies required to bring about the transformation. EA, BPM, L6SS, Project Mgmt etc all have vital contributions to make.  The change leader should be the party responsible for customer satisfaction, employee well being and profitability, the team should be made up of a cross section of process (business), IT and employee competence experts.”

What is your experience when working between EA and BPM roles? Please share your story!

Job Description for Business Architecture

By |2010-02-03T05:54:42+00:00February 3rd, 2010|Enterprise Architecture|

As the result of reading some discussions on the responsibilities of Business Architecture, I got to thinking: How to describe the list of prerequisites for Business Architect, and what is the career ladder that I believe a good BA goes through?

I did a quick bing search to see if other folks had attempted to answer this question.  While there are a few job postings on various boards, there are surprisingly few discussions of job skills or a job description.  One notable exception was posted in the summer of 2009 on the BPMI site, but that one is not particularly distinct from Enterprise Architect. (see below)  For this blog post, I started with the posting by Geoff Balmes from the BPMI site, made a few edits to clarify the distinction from Enterprise Architect, and posted it here.   

Qualifications of a Business Architect

Role
The Business Architect analyzes the activities of a particular business unit or line of business and makes recommendations pertaining to the projects that the business unit should perform, in addition to relevant and timely corrections to the governance structure, business processes, and the structure of business information. This person illustrates the alignment (or lack thereof) between strategic goals and key business decisions regarding products and services; partners and suppliers; organization; capabilities; and key business and IT initiatives. The primary focus of this person’s work includes the analysis of business motivations and business operations, through the use of business analysis frameworks and related networks that link these aspects of the enterprise together. The Business Architect works to develop an integrated view of the business unit, in the context of the enterprise, using a repeatable approach, cohesive framework, and available industry standard techniques.

Organization
The Business Architect reports into business management and works closely with other business architects, enterprise architects, and counterparts in Information Technology. The Business Architect may have supervisory responsibility, possibly acting as coach and mentor to junior colleagues in a similar or reporting role. In addition, the Business Architect works though others at every level of the organization soliciting strategic imperatives from senior leaders and executives, and supporting business unit managers as they leverage business architecture artifacts to create their business plans. Finally, the Business Architect may provide direct input into the governance cycle for the funding, oversight, and realization of business projects.  In that governance role, the business architect helps to insure that business and IT projects are aligned to support the achievement of key goals, that specific business scenarios are considered and that business value is delivered. 

Responsibilities

  • Develop a business architecture strategy for the business unit based on a situational awareness of various business scenarios and motivations.
  • Apply a structured business architecture approach and methodology for capturing the key views of the business unit in the context of the enterprise.
  • Capture the tactical and strategic business goals that provide traceability through the organization and are mapped to metrics that provide ongoing governance.
  • Describe the primary business functions of the assigned business unit in the context of the enterprise and distinguish between customer-facing, supplier-related, business execution and business management functions.
  • Enumerate, analyze, catalog, and suggest improvements to the strategic, core and support processes of the business unit, as needed, to support strategic and operational goals.  
  • Define the data elements shared between this business unit and other units in the enterprise and the relationships between those data elements and processes, people, systems, and other data elements.
  • Enumerate, analyze, and suggest improvements to the structural relationships of the business.  This requires the creation and maintenance of an ongoing model of roles, capabilities and business units, the decomposition of those business units into subunits, and the interplay between these units in various business processes, materials, people, and systems.

Skills and Qualifications

  • A broad, enterprise-wide view of the business and varying degrees of appreciation for strategy, processes and capabilities, enabling technologies, and governance
  • The ability to recognize structural issues within the organization, functional interdependencies and cross-silo redundancies.  Those issues may exist in role alignment, process gaps and overlaps, and business capability maturity gaps
  • The ability to apply architectural principles, methods, and tools to business challenges
  • The ability to assimilate and correlate disconnected documentation and drawings, and articulate their collective relevance to the organization and to high-priority business issues
  • The ability to visualize and create high-level models (rigorous information-rich diagrams) that can be used in future analysis to extend and mature the business architecture
  • Experience developing and using these high-level models as required to collect, aggregate or disaggregate complex and conflicting information about the business
  • Extensive experience planning and deploying either business or IT initiatives (preference for both)
  • Experience modeling business processes using a variety of tools and techniques (preference for BPMN)
  • Exceptional communication skills and the demonstrable ability to communicate appropriately at all levels of the organization; this includes written and verbal communications as well as visualizations
  • The ability to act as liaison conveying information in suitably accurate models between the business unit and their counterparts within Information Technology.  The scope of this information includes business requirements, data constraints, business rules, models of strategy and motivation, processes, accountabilities, and many other business and IT operational needs 
  • Must be a Team player able to work effectively at all levels of an organization with the ability to influence others to move toward consensus.  Must be highly reliable, trustworthy, honest, and commitment oriented
  • Strong situational analysis and decision making abilities

The Career Ladder of a Business Architect

Describing the career ladder of a business architect is difficult for many reasons.  This is a new field, and the business architects that I know arrived at their career from different directions and are likely on different trajectories.  What I can say is this: becoming successful at business architecture is an extremely useful skill in many aspects of corporate life, and can provide very useful insight and connections into upper echelons of management. 

To become a business architect requires strong business skills.  A degree in business is more than helpful… few business architects will succeed without one, although a decade or more of experience in an industry can make up the difference.  Note that I’m not focusing on consultants who perform a business architecture assignment, but rather on full time employees who would be able to perform this role.  A firm understanding of structural models is the next prerequisite skill and this kind of thinking is often found in people who “think visually.”&#160
; Look for creative individuals in accounting, marketing, and information technology who can tend to draw diagrams in their presentations that represent the relationships between concepts, people, processes, or business functions.

Once you have proven successful as a business architect, the next step depends on you.  The obvious next step is to the role of enterprise architect.  To be a successful EA, one should have been successful at one of the key EA roles (Business, Solution, Information, or Technology Architecture) and have a reasonable grasp and appreciation for the other roles.  Not an easy step.

Another direction for the successful Business Architect is into business management.  A BA can see relationships that most mid-level managers have never been trained to look for, and have a rich understanding of how to use that information. 

How a Business Architect is different from an Enterprise Architect

I personally consider an Enterprise Architect as a person who can perform as both Solution Architect (SA) and a Business Architect (as needed) and has some ability as an Information Architect.  In addition, an EA can perform at an enterprise level, something that is NOT required of either an SA or BA.  What this means, in my opinion, is that you should not call yourself an Enterprise Architect unless you have full capability as both a BA and an SA and at least partial capability as an IA.  (No, a course on the Zachman Framework or TOGAF is not sufficient). 

In Zachman terms, an EA has to be able to perform across ALL ROWS AND COLUMNS of the framework.  A Business Architect doesn’t have to extend below row 2 or perhaps 3, while a Solution Architect usually lives in the lower rows.  An Information Architect, at the enterprise level, must be able to run the gamut of a single column of the Zachman framework. 

How do you measure Enterprise Architecture?

By |2009-03-06T11:52:05+00:00March 6th, 2009|Enterprise Architecture|

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…

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.

Feedback requested: Information driven process design

By |2008-12-17T16:58:38+00:00December 17th, 2008|Enterprise Architecture|

An esteemed associate of mine asked me recently if I believe that a conceptual information model, created and delivered independently from a process model, can be considered useful when attempting to improve a business.  In other words, if you have an conceptual information model, can you use it directly, or do you need to produce a process model as well?

The answer, as is typical of EA answers, is buried in the question.  If the goal is to improve a business measurable (like customer satisfaction, or average dollars per order, or customer acquisition cost), then the information model is not useful by itself.  A process model that illustrates how the information is generated and managed must also exist.

So we will often need to develop both a conceptual model of a business and a process model for the business… but which comes first?  Must they be done in parallel?  Or should an architect create one before the other?

Personally, I know of cases where a process model existed long before a conceptual model did, and vice versa, so clearly the efforts are not contingent upon the other.  In fact, in the situation I am in right now, the business has defined a rich process model that has grown out of date.  I have separately developed a conceptual information model that includes concepts considered important by the stakeholders.

Now comes an interesting question: how do we take an updated conceptual information model and use it to improve an existing (but dated) process model?

I have my ideas, but I’m wondering if you, gentle reader, have specific ideas to share as well?  I’ll outline my thinking, but I invite a discussion: is there a better way?

Situation: a project team finds that they have a conceptual information model, and/or business vocabulary, that is not in sync with the processes that the business says they want to standardize upon.  How do we use one to improve the other?

Nick’s method:

  • Step 1: insure the conceptual model reflects the complete breadth of the process model.  This requires going through the process model and identifying all elements referenced, and insuring that they are correctly represented in the information model.  Capturing nouns, verbs, and relationships is key to this step, as are the negotiation skills needed to get everyone to agree on the resulting diagram.
     
  • Step 2: identify entities on the information model that are key entities.  Indicators of key entity:  (a) many different stakeholders define the entity as important to their work, (b) the entity is necessary to model the primary relationship between two other key entities, or (c) the entity is part of a key business measure.  An example of the third indicator: if the business scorecard includes a measure of “number of open incidents” then the term ‘incident’ is a key entity.
     
  • Step 3: establish dependency relationships for key entities.  It is common for one data entity to depend upon another.  The ‘order’ entity depends upon the ‘product’ entity, for example (in most businesses, it is difficult to order a product that the business does not have in their catalog). 
     
  • Step 4: define a loose process model that describes each of the lifecycle events of the key entities on a timeline: when is the entity data created?  When is it used?  When is it updated?  When is it archived? When is it deleted?  Drill down on the steps to identify where specific information must enter the process in order to manage the information.
     
  • Step 5: compare the newly generated “loose” process model to the out of date process model in existence.  Use the new one as a guide to making incremental changes to the existing process model. 

OK… that’s a swag.  Does anyone have a reference to a well documented and sound methodology for taking a conceptual information model and using it to improve an existing, and potentially out of date, process model?

Input sought: Actor – Role – Process Activity… an interesting domain model question

By |2008-09-29T00:36:00+00:00September 29th, 2008|Enterprise Architecture|

I have an open question.  I’d love to get community feedback.

A process can be decomposed into activities.  Who performs the activities?  Are activities performed by roles with actors assigned to those roles, or are activities performed by actors in roles?  In other words, is it a binary or ternary relationship?

Pedantic question, perhaps, but this is the kind of thing that causes heartburn when creating a domain model for IT management.  Understanding these relationships is important if we are to build software that allows an IT person to correctly capture and describe business processes.

Here are these two options, in detail…

View 1:

image

Ternary relationship: an activity is performed by an actor in a role.  One consequence of this connection is that a person or system (actor) is directly traced to the processes that the actor performs.  The assumption being that any actor can play any role in any process, including many roles.  It also assumes that an activity cannot be described using only a role, but MUST be described by both a role and an actor.  Another major difficulty with this view is that it is very difficult to demonstrate that conflicts of interest have been addressed, as required by corporate best practices and, in many cases, legislation.  By containing an actor within a role, it is possible to demonstrate that an actor has remained compliant.

View 2:

image

Two binary relationships: An actor behaves in a role, and an activity is performed by a role.  One consequence of this connection is that a person cannot be directly traced to the process, since an actor is part of a role, and a role performs an activity in a process.  This is a simpler relationship, and it allows us to describe a process activity as “performed by a role” without any notion of the specific actor that will fill that role.  This appeals to the notion of encapsulation, and allows us to constrain an actor to a role.  On the other hand, this structure does not represent reality.  The notion of a person, performing a role, within an activity is better for tracing the actual events, because a person may act outside of their assigned role, and perform an activity in another way. 

Potential resolution:

image

Supposition: Both views are correct.  From a planning perspective, we can insure compliance with policy by requiring actors to perform within a role, and attaching the role to the process.  Then, when recording actual activity, we would record that an actor, behaving within a role, performed the activity, regardless of whether they are actually assigned to that role.  This allows good auditing, while insuring that compliance to policy and legislation is demonstrable.

Feedback?

The reason I pose this as an open question is to ask you, gentle reader, if you view this relationship in a different way.  What does your experience tell you?  What concerns would not be addressed by the potential resolution, or have not been considered in the two views?

Addendum

Jim Ludden points out, in the comments, that I had not defined the terms involved.  So here goes:

Role

  • Prescribed or expected behavior associated with a particular position or status in a group or organization. (BusinessDictionary.com)
  • The actions and activities assigned to or required or expected of a person or group (Wordnet, Princeton University)

Actor

An abstraction of a person or group of people, described through an understanding of their motivations and pre-existing conditions.

Process Activity

A single logical step in a business process. (Source: WfMC Glossary)

Looking up the definitions was valuable, because it makes it more clear that the definition of a role is not independent from the understanding of the activities themselves.  In effect, a role is an assignment of activities to an actor.  Pretty much makes “option 1” a non-sequitur.  The rest of the analysis is useful, however, in that we can describe what a person Can do, and then in a seperate way, what a person Did do.  Thanks to JimL.

Clarifying the Concept of Metadata

By |2008-09-17T03:42:00+00:00September 17th, 2008|Enterprise Architecture|

Metadata is a difficult word to define, or so it would appear.  After all, why is it that the best that Wikipedia can do is:

Metadata (meta data, or sometimes metainformation) is “data about data”, of any sort in any media. An item of metadata may describe an individual datum, or content item, or a collection of data including multiple content items and hierarchical levels, for example a database schema.  (Source: Wikipedia)

Ewww. 

OK, to be fair, that’s not the best definition I could find, but I did want to point out one problem with the way that Metadata is perceived in the world of computing.  Metadata is usually defined in some lame way (data about data) and then described through examples, to help people to understand the meaning of the term.  Those examples are often incomplete or even misleading, like the example above or this example from further down in the same Wikipedia article:

In the context of an information system, where the data is the content of the computer files, metadata about an individual data item would typically include the name of the field and its length. Metadata about a collection of data items, a computer file, might typically include the name of the file, the type of file and the name of the data administrator.  (Source: Wikipedia)

What is so bad, you might say, about this example?

After all, it conveys the concept of “data about data” using terms that the reader may find familiar.  That is true, but there are much more powerful, complete, and correct examples available, ones that would provide a richer context to an understanding of metadata, and perhaps an understanding of how important metadata can be.  In addition, by supplying a small set of metadata elements, the example tells such a small part of the story, that it errs by omission.  It would be akin to describing a political leader as “human” and supplying their date of birth.  There is considerably more information that is both useful and simple to collect.

For example, let’s say that someone sends you an e-mail, and in that e-mail is a document.  The name of the document is “Functional Specification for Vista.” You could draw all kinds of conclusions from that bit of metadata (the title). 

Now, you open the document and you find that it is a short document (one page).  On that page is a list of the people, and their business functions, who proofread text submitted to a commercial printing company called Vista Printing.  Or even better, it turns out it is a Powerpoint deck, created by a salesman, that shows pictures of how Vista Printing functions!

After examining the metadata, what was missing from our understanding of this document?

We could (and I argue, should) know a great deal more about an artifact like this one, before we can say that we understand it.  We need to know, at least, who, what, when, where, why, and how. 

  • Who created the artifact?
  • Who is the intended recipient?
  • Who has accessed it?  (And when did they access it, and what process were they performing when they did?)
  • What business process called this artifact into existence?
  • What business outcome was it intended to support?
  • When was it created (date)?
  • When was it created (in what relation to the beginning of the process instance in which it was created)?
  • Where was it created (physical systems used to create it)?
  • Where is its address (URL?) for it’s ‘official’ storage location on a network?
  • Why was it created (name of the process activity that required this artifact as input)?
  • Why was it created (description of the personal objective of the creator in creating it)?
  • How was it created (using what tools and techniques)?
  • How was it created (using what thinking / creative / collaborative process)?
  • How was it created (using what audit / change control / approval process)?
  • How was it paid for (which goes to the motivation of the person who desired it’s creation)?

While it is true that the creation date and file name are, technically metadata, they are far from reasonable examples to help people understand the concept of metadata.

To this end, I’ll suggest an alternate definition: one that I believe is simple, easy to read, and provides a better understanding than ‘data about data.’  It goes like this:

Metadata is the surrounding contextual information required for a person or system to “understand” an element of information in the context for which it was intended. 

Metadata answers fundamental questions about a bit of information, such as who created it, who may access it, what does it refer to, why it was created, and how it should be used. 

A sufficient amount of metadata is captured when a consumer of a data element is able to correctly place the information in context, even if that consumer is using the information for a different purpose than it was originally intended.  The list of fields considered ‘sufficient’ for one purpose may not be sufficient for another.

Of course, you may not want, or need, all of those questions answered.  It can be difficult to capture everything, and some of those difficult items may not be beneficial for any of the consumers of that information. 

On the other hand, it would be very simple, in many cases, to capture quite a bit of metadata, nearly always more information than we normally capture.  Capturing this information, and using it appropriately, can help in the automation of business processes, the correct categorization of information for retrieval (and use), demonstration of compliance to a standard or business rule, and the maintenance of appropriate information security.

The data that we frequently collect, like the user who created it, or the date it was updated, is not interesting if there is not a business process that ties to that data, either as a producer or consumer.  How many database tables have columns for ‘last modified date?’  How many business processes use that information?

So, whether you are working on a repository of information, or just creating the schema for a database, consider carefully what metadata you want to capture and how you want to capture it.  Ask yourself who, what, when, where, why, and how, both for fields and tables.  Ask these questions for all artifacts, including the documents, source code, and test execution logs.  Then, consider carefully if that information would be useful to a business process somewhere else in your system. 

Capture useful metadata.  You’d be surprised how valuable it can be.

How BPM does, and does not, support people

By |2008-09-12T15:21:00+00:00September 12th, 2008|Enterprise Architecture|

Kudos to Andrea Westernien on her blog about the disjoint between the work that people do and business process automation.

Andrea, who blogs under the title of ‘Policy Based Business blog,’ used eloquent words to capture what I was originally trying to say in my (considerably less eloquent) posts (here and here) on the successes, and failures, of automated business process management. 

My posts were attacked by one BPM analyst, Bruce Silver (here), with a few other bloggers offering their perspectives (example here). Hopefully, many people will take the time to understand this concept by reading Andrea’s well reasoned, and well written, post. 

Andrea also describes a solution that she feels may help.  I have yet to evaluate the solution she cites.

Working in the dark

By |2008-08-30T16:05:33+00:00August 30th, 2008|Enterprise Architecture|

If we listen to smart people who create development processes, we hear things like "collect requirements" and "understand business process."  We then go and write use cases, design software components, and write code.  Test cases describe the things we are going to test, and automated tests allow us to test our systems over and over.  Build scripts and deployment scripts and maintenance scripts automate complex tasks.  Whew!

There’s a lot of stuff in there.  And that is just the software development process.  But software development is part of a much larger process. 

When you start to consider the end-to-end processes, you have to consider the planning and operations aspects.

Planning includes things like business strategies, trends, business programs, scorecard measurements, metrics, scenarios, business capabilities, high level business processes, business functions, divisions, roles, teams, budgets, roadmaps, and rollout plans. 

Operations teams have even more considerations, leveraging things like configurations, change plans, incident reports, problem statements, service levels, events, assets, and services.  Assets include servers, systems, components, databases, and network components. 

Why the litany?

I’m trying to make a point.  Many people are involved in running a business, and many are involved in making changes to the business, ostensibly to improve it.

If you write software, or work in IT, you are part of that system as am I.

But if we don’t understand, even on the surface, the entire system by which the business operates, we are working in the dark.  We can’t see how our work affects others, and we can’t see how important (or unimportant) it is that we perform our responsibilities well.

Most importantly, without seeing the system, it is tempting to make things up. 

For example: If we don’t see how the requirements we gather connect to the business processes, we might be tempted to ignore the processes and simply invent requirements that "make sense" … to whom?  the project manager? The customer representative?  What makes the requirements "correct" if we have nothing to connect them to?  I’ve seen this happen many times.  It is crazy, but typical.

Another example: if we don’t see how our services are connected to enterprise information models, we can’t see if we are creating a service that avoids unintended consequences, or would create problems for managing data, or requires a process to "Magically" come into existence, complete with staffing and expertise, that the business is not expecting.

It is critical for the people involved in software development to understand the entire system of corporate operations, even at a visceral level.  IT teams must have access to the system of processes, especially as that system changes over time.

Over the next few months, I expect to be writing more about this understanding… How to see the system, and how to connect your parts to the "whole." 

There is a lot to understand, and learning is a process.  Each day, I consider myself a student, and a day is well spent when I did two things: used my understanding to help someone, and learned something new.  As I write, I am learning, so I’m inviting you, gentle reader, to share this journey with me.  Share the things you have learned, and the perspectives from your own experiences. 

Instead of working in the dark, let’s light some candles…