traceability Archives

Creating a Core Diagram for Agile Business

By Nick Malik|2012-01-31T16:47:00+00:00January 31st, 2012|Enterprise Architecture|

Today, I gave my talk at the Open Group conference that presents a step-by-step method for creating a core diagram that is useful for agile business. I will blog a series of posts on the topic to share this information to my friends and colleagues on the web.

I will create the following posts. As I do, I will come back and edit this post to provide a link. This post will stand as an introduction and table of contents to the topic.

I will post the following articles:

What is a core diagram and what value does it provide?
What are the high level steps to producing a core diagram?
Who cares about a core diagram and what are the scenarios for use? What should be represented?
What is Minimum Sufficient Business Integration (MSBI) and when should this method be used?
Step-by-step instructions for the MSBI method and outputs produced
Testing and Landing the core diagram in your business and governance processes

This will likely take a few days, and I’d like to take a few minutes to describe each of these topics. The talk lasted 45 minutes (at a wildly accelerated pace). I plan to provide a better, albeit slower, set of information for the folks who read this blog.

Nick Malik speaking at the Open Group conference, Jan 31, 2012, San Francisco

If you’d like to see the original presentation, see the following slideshare presentation:

Open Group Presentation on MSBI method of creating Enterprise Architecture Core Diagrams

View more presentations from Nick Malik.

1

Enterprise Business Motivation Model version 3.5

By Nick Malik|2011-07-27T00:26:07+00:00July 27th, 2011|Enterprise Architecture|

For those of you who have been waiting for me to announce the release of the newest version of the Enterprise Business Motivation Model, I’m happy to announce that version 3.5 is available now.

To visit a WordPress site set up to explain the model, visit http://motivationmodel.com

To visit a web site produced by the Sparx modeling tool, allowing direct navigation of the model itself, visit http://motivationmodel.com/ebmm

To download a PDF document exported by the modeling tool (for those folks who love PDF files), visit this link here.

Special Thanks

The Enterprise Business Motivation Model has gone through a long list of changes since the original article was published over two years ago. I’ve spent considerable time working through the model and getting feedback from colleagues from around the world.

I’d like to give special thanks to Michael Davison, JD Beckingham, Neil McWhorter, Bruce McNaughton, Henk Harms, Bill Ulrich, Jim Rhyne, Kirk Rheinlander, Leo de Sousa, Yelena Edelstein, Al Newman, Amy Nguyen, David Vugteveen, and many others who have commented, criticized, and asked for clarifications. Without your concerns and your insight, the EBMM would not move forward. Thank you!

Changes to look for

There are many changes since the last public version (v1).

The business model description was updated to reflect connections between customer types and partner types, and to more completely cover the model elements of Alexander Osterwalder’s Business Model Generation. (model, description)
Porter’s Five Forces was added as a separate area clarifying the linkage between a Five-Forces analysis and business models themselves.
The dual notion of Business Capability and Business Unit Capability proved too confusing and arbitrary for a core conceptual model. The single concept of Business capability remains.
The concept of Data object is now elevated to a top-level element in the model with necessary changes to the high level view.
Business role was added with relationships to business processes and data objects.
The concepts of Regulations, Legislative Edicts and Charter Legislation were added to clarify the role of these key concepts to Government and Semi-private organizations.
The concept of “capability maturity” was expanded to “assessment metric” to allow a broader understanding of how measures can be applied to business capabilities in order to motivate and measure the success of initiatives.
Clear distinctions are made between an enterprise, a company, and a business.
An additional relation has been added to business unit: relates to. This allows models of the enterprise to include interrelationships between business units other than the normal hierarchical relationships that the existing “includes” relation allows. This should enable a wider array of analysis models to be created for those architects who need to model a subset of the enterprise.
A page was created on the WordPress site to discuss the difference between a Process and a Capability. (link)

Of course, we are not done. I am publishing version 3.5 in order to insure that my conversations with other Business Architects has a current footing. The following concerns have been shared and are under consideration for future versions:

Add the ability to attach a Value Chain Analysis
Add the ability to represent the accountabilities of a team in relation to the business processes themselves
<<your suggestion here>>

As always, I welcome feedback and input. I’m proud of where the EBMM has come so far and look forward to working with exceptional people to discuss and describe future changes to the model.

Note: I didn’t keep a careful list of the folks who offered valuable feedback on the model. If you offered feedback, and I didn’t mention you above, please accept my apologies and send me a note. I’ll update this post.

0

Metamodel 101

By Nick Malik|2011-05-26T17:42:17+00:00May 26th, 2011|Enterprise Architecture|

I was just privy to a conversation about the value of creating a specific kind of metamodel, and it made me wonder… if I had to explain the concept of a metamodel to someone, how would I do it?

First, let’s start by defining the term “metamodel.” The IEEE Online Software Engineering Vocabulary (SEVOCAB) provides 12 different definitions for the term ‘metamodel’. In my opinion, the definition most applicable to enterprise architecture is this one:

CDIF semantic metamodel. (1) the description of the set of concepts and notations used to define a model (ISO/IEC 15474-1:2002 Information technology — CDIF framework — Part 1: Overview, 4.2) Note: The CDIF semantic metamodel defines an Entity-Relationship-Attribute model that is used to construct and define models used in systems development.

Peel away the jargon, and you get this: a metamodel defines the stuff that you put into your models.

For example, I created this model of a fictitious company, Contoso. They have created some strategies, and the Enterprise Architect has tied those strategies to business initiatives and those business initiatives to the business units that are impacted by those initiatives. (A simple traceability model).

If the diagram above is a model, what is in the metamodel? That’s the diagram below:

In this metamodel, we provide definitions for three terms: strategy, initiative, and business unit. They are meaningful in the context of the model and should have a single definition. In addition, the metamodel defines every relationship that is allowed between these elements. We can say that an initiative may involve a business unit, but our model cannot show the relationship of a business unit to a strategy UNLESS there is an initiative that is aligned to that strategy and which involves the business unit.

A metamodel restricts what you can draw. It prevents you from drawing things that don’t make sense. And it clearly defines the terms so that when someone reads your model, they know WHY you described some things as strategies and other things as initiatives (for example).

A metamodel is the grammar and definitions of words. It provides the dictionary. The model itself is the story you tell with those words.

Tutorial over for the day!

2

It’s not about cost savings… it’s about value

By Nick Malik|2011-03-01T10:57:59+00:00March 1st, 2011|Enterprise Architecture|

The word ‘value’ has too many meanings and sometimes it masks a real problem.

I had a conversation with a very smart customer recently, where their IT division is going through a transformation to help their business compete. I asked if their transformation has the purpose of making IT cost less or increase business agility. Their answer: It’s less about cost and more about value.

To me, an answer like that is vague. It sounds good, but what kind of value is IT supposed to deliver?

And that is the core question we should always ask of the business. We shouldn’t be asking IT to deliver “generic” value. We should be asking IT to deliver specific value, to make changes that will meet specific business goals. And that requires that the business describe their strategies in terms of specific business goals.

Getting alignment to “generic value” is like having a teenager tell you that their room is clean. Too many definitions of the word.

Alignment without specificity is not possible.

5

When Traceability is a “Bridge to Nowhere”

By Nick Malik|2010-01-23T13:57:18+00:00January 23rd, 2010|Enterprise Architecture|

One thing that many Enterprise Architects agree with: traceability matters. If your job is to help the business to determine the strategic initiatives they should follow this year, the EA answer is to look to their goals and TRACE from their goals to their capabilities and, based on areas of weakness, TRACE to the initiatives that improve those capabilities.

The painful reality is that tracing from business goals may illuminate a decision that a business user is uncomfortable hearing. For example, if a senior leader tells a general manager to “Solve Problem X”, and you are working with the team under that general manager, it is tough to tell that team that they are solving the wrong problem. They really can’t handle that news, because they are not paid to question the directive. They are paid to make it come to pass.

In this situation, traceability is a two-edged sword. Traceability illustrates strengths, but it also illustrates weaknesses. So if you ask the project team to tell you about the business goals, they will respond: the goal is to “Solve Problem X.”

For the project team, there is no traceability above the directive. No one can demonstrate traceability to anything that looks like business value or return on investment or business agility. They are doing work because the big boss told them to.

The best that the project team can do is to try to find business value in “solving” problem X. If there is far greater value in solving problem Y, and that simply makes problem X disappear, the project team will not be able to see their way there. What’s an Enterprise Architect to do?

In those cases, you may be forced to do what I sometimes do: write down the assumptions that the team is taking, and NOT show your team how badly the assumptions trace to the business goals. Just start with the assumptions and work from there. Your models will be wrong, but you will deliver output and build credibility.

Later, when you get a chance to present to the senior leader, don’t (just) talk about the (possibly wrong) results. Talk about the assumptions. See if he or she agrees.

To do this, you may need to produce many what-if models. One that the project team has signed off on, and a couple that they have not. When presenting to the senior leader, see if you can guide the conversation with the to consider alternatives, and then be ready to challenge the assumptions with real ideas. You may not be able to convince everyone, but at least you will have had the conversation. That is one of the most important things an EA can do.

In this case, from the standpoint of the project team, traceability is not valuable. If anything, it is counterproductive because it runs the risk of making them look like they are doing the wrong work. But it is valuable in the end to make the enterprise successful.

Traceability matters to Enterprise Architects. For some of our stakeholders, it is not valuable at all. For a few, traceability is frightening. For those stakeholders that won’t see value, don’t demonstrate traceability. Traceability from goals to initiatives is a model that should not be shown to everyone.

And that, unfortunately, is one tradeoff of being an Enterprise Architect.

10