Search Results for: open group

Should Business Architects use the Business Model Canvas at the Program level?

by

In the Open Group conference at Newport Beach, I listened to a series of presentations on business architecture.  In one of them, the presenter described his practice of using Osterwalder’s Business Model Canvas to create a model of his program’s environment after a business program (aka business initiative) is started.  He felt that the canvas is useful for creating a clear picture of the business impacts on a program.  There are problems with this method, which I’d like to share in this post. 

Let me lay out the context for the sake of this post since there is no business architecture “standard vocabulary.” 

A “business program” is chartered by an “enterprise” to improve a series of “capabilities” in order to achieve a specific and measurable business “goal.”  This business program has a management structure and is ultimately provided funding for a series of “projects.”  The business architect involved in this program creates a “roadmap” of the projects and to rationalizes the capability improvements across those projects and between his program and other programs. 

For folks who follow my discussions in the Enterprise Business Motivation Model, I use the term “initiative” in that model.  I’m using the term “program” for this post because the Open Group presenter used the word “program.”  Note that the presentation was made at an Open Group conference but it does NOT represent the opinion or position of the Open Group and is not part of the TOGAF or other deliverables of the Open Group.

The practice presented by this talk is troubling to me.  As described, the practice that this presenter provided goes like this: Within the context of the program, the business architect would pull up a blank copy of the business model canvas and sit with his or her executive sponsor or steering committee to fill it out.  By doing so, he or she would understand “the” business model that impacts the program. 

During the Q&A period I asked about a scenario that I would expect to be quite commonplace: what if the initiative serves and supports multiple business models?  The presenter said, in effect, “we only create one canvas.”  My jaw dropped.

A screwdriver makes a lousy hammer but it can sometimes work.  The wrong tool for the job doesn’t always fail, but it will fail often enough to indicate, to the wise, that a better tool should be found.

The Osterwalder’s business model canvas makes a very poor tool for capturing business forces from the perspective of a program.  First off, programs are transitory, while business models are not.  The notion of a business model is a mechanism for capturing how a LINE OF BUSINESS makes money independent of other concerns and other lines of business.  Long before there is a program, and long after the program is over, there are business models, and the canvas is a reasonable mechanism for capturing one such model at a time.  It is completely inappropriate for capturing two different models on a single canvas.  Every example of a business model, as described both in Osterwalder’s book and on his web site, specifically describe a single business model within an enterprise.

I have no problem with using business models (although my canvas is different from Osterwalder’s).  That said,  I recommend a different practice: If the business initiative is doing work that will impact MULTIPLE business models, it is imperative that ALL of those business models are captured in their own canvas.  The session speaker specifically rejected this idea.  I don’t think he is a bad person.  I think he has been hammering nails with a screwdriver.  (He was young).

Here’s where he made his mistake:

multistream value chain

In the oversimplified value stream model above, Contoso airlines has three business models.  The business owners for these three businesses are on the left: Bradley, Janet, and Franklin.  Each are primarily concerned with their own business flows.  In this oversimplified situation, there are only two programs, each with one project.  If the session speaker were working on the Plantheon program, his idea works.  there is only one business model to create.  That nail can be hammered in with a screwdriver.  Lucky speaker.  Showing Franklin his own business model is a good thing.

But if we are working on the Flitrack program, what do we show Franklin?  if we create a “generic” canvas that includes cargo, he will not recognize the model as being applicable to his concerns.  He will not benefit and neither will the program.  In fact, Franklin will think us fools because he had a presentation from Plantheon yesterday showing him an accurate model… don’t you people talk?

Program Flitrack should have one-on-one conversations with Bradley and Janet to develop their business models.  The business model that Franklin cares about does not need to be created again.  It can come out of the repository.  The Flitrack program would consider all three models as independent inputs to the business architecture of the organization impacting the program. 

Anything less is business analysis, not business architecture.

Protecting Data is Good. Protecting Information Generated from Big Data is Priceless

by

This was the key message that came out of The Open Group® Big Data Security Tweet Jam on Jan 22 at 9:00 a.m. PT, which addressed several key questions centered on Big Data and security. Here is my summary of the observations made in the context of these questions. Continue reading →

Rumination on the concept of “best practice”

by

I heard some very interesting talks today from Len Fehskens and Jeff Scott at the Open Group conference.  One thing that I picked up in a meeting yesterday was the notion that TOGAF 9.1 is built on “best practices.”  Today, as Jeff spoke about the transformation of a technical architect into a business architect, and as Len spoke about the challenges of communicating complex ideas, the notion of a “best practice” kept bothering me, and I cross-pollinated my concerns with the concepts that they were sharing.

I agree that the intent of the people who shared their practices with the Open Group was to provide practices that can be taught and followed.  I even agree that the people on the TOGAF committees that accepted the content felt that the practices represented the best that the industry had to offer at the time.  But I wonder if any of the work done in framework committees of any stripe (not to pick on the Open Group) can be held to the standard of being a “best practice.”

Are the practices in the TOGAF framework truly “best��� practices?  Are these practices the best ones that the EA field has to offer? 

I guess I would have to follow the EA rabbit hole and ask “what criteria do we use to judge if a practice is the best one?”

After all, when Jeff Scott talks about business architecture using capability modeling, he believes that the practice of capability modeling is the best one to use for the results he is trying to achieve.  (I nearly always agree with Jeff, BTW.  We sometimes differ in language, but nearly never in approach).  That said, as much as Jeff and I agree, our agreement does not mean that the practice should be considered a “best” practice.  Who are we to say?  We are practitioners.  While that is good, it is not enough in my mind to qualify the practice as “best.”

To be a best practice, in my opinion, a method or approach has to meet a higher bar.  There has to be evidence that it is, in fact, better than just a “good practice.” 

I think a best practice should have:

  • Some measurement (evidence) that demonstrates that it is an effective practice, and that the measurement shows that it is at least as effective as other practices,
  • A clear understanding of the results of the practice and the context in which it is to be performed (think “Pattern Language” criteria),
  • Some analysis to show that it meets other criteria like broad applicability and simplicity, and
  • We should demonstrate the ability for that practice to be understood and performed by people who are currently in the role (e.g. can we teach it, and if we teach it, can others do it?).

 

I wonder if we went through most of our frameworks and highlighted the text that is able to meet a higher bar, like the one I describe, how much of the text would we cover?  2%?  10%? 

Is 10% coverage enough to say that a framework is based on best practices?

How Should we use Cloud?

by

How should we use Cloud? This is the key question at the start of 2013. The Open Group® conferences in recent years have thrown light on, “What is Cloud?” and, “Should we use Cloud?” It is time to move on. Continue reading →

The unique contribution of enterprise-architecture

by

What do enterprise-architects actually do? What unique contribution do they bring to the enterprise? What triggered this was one paragraph in Len Fehskens’ item on current and future enterprise-architecture, in the Open Group blog ‘2013 Open Group Predictions, Vol.1‘. Here’s the…

Steps To Create a Core Diagram

by

To be fair, these are steps to create a solid understanding of the architecture of a business, but the deliverable is a core diagram, so that’s the title of the post.  I first wrote about a method for creating core diagrams about a year ago, as I was preparing for a talk on the subject at the Open Group conference in San Francisco.  Now that I’m preparing for another Open Group conference, I find myself filling out some of the details from the previous effort.  Most of the text below is copied from an e-mail that I sent to a fellow business architect who was asking about how to create a core diagram.

The text below describes a five step process

  1. Collect a list of your organization’s business models
  2. Create or leverage a taxonomy of capabilities that reflect differentiation in business processes
  3. Differentiate each capability on the basis of Ross’ operating model taxonomy (level of Information Integration and level of Process standardization)
  4. Make an educated guess about the operating model of the company
  5. Draw the core diagram and build understanding around it

 

Understanding how to create a core diagram starts by collecting a list of the business models that your organization performs. Each business model is unique and different from the other ones. Each will require different capabilities and will often drive variations in those capabilities for the sake of market or product differentiation. You cannot create a core diagram effectively without the list of business models.

So what is in a business model? I’ve blogged about that fairly well. A business model is a composition of elements that describes how and why a value proposition exists, who it is for, and what it drives in terms of internal and external requirements. The diagram is below. (click to enlarge)

Metamodel for a Business Model

Once you have the initial list of business models, you will want to engage with direct business stakeholders. Make sure that they understand the concept of a business model, and what makes a business model unique from other business models (e.g. selling the same product in the same way to the same people in another country is NOT a unique business model, but selling a product in three different ways to three different, potentially overlapping market segments within one country probably represents three business models). Engage. Build relationships. This is your first shot.

Once you have that list fairly well baked, you have step two on your hands: a capability taxonomy that reflects process differentiation. In this case, it is a good idea to start with a high level process taxonomy like the ones made available for free from the APQC. I don’t know if there is one for financial services yet, but there should be. If not, you can start with a general one, but it will take some editing. You want your capability taxonomy to be worded in such a way that it represents “things that could be done” without reflecting the way in which they are done. For example, “customer identity management” is OK, but “customer deduplication” is not, because we want to make sure that customers have an appropriate identity but the organization may not want to remove duplication in order to do that.

This requires some editing of a large list of items in a hierarchy. Excel is OK for this. There may be other tools as well… I haven’t experimented past Excel. This is the second point where it is good to be engaging with business stakeholders. Get their help to describe their business model to you in terms of capabilities, and make sure that all of their capabilities are included in your taxonomy somewhere (usually around the third level down in the tree).

Step three is to differentiate each business capability on the dimensions suggested in the EA As Strategy book. (This can be done at a high level. If your taxonomy has more than 200 business capabilities in it, don’t use the most detailed level(s) of the taxonomy. No one has patience for the details in a core diagram.

Draw out a grid like the one illustrated in the EA As Strategy book, only make it empty.

Diagram illustrating the dimensions of Operating Models with Integration (low and high) on the Y axis, and Standardization (low and high) on the X axis

In each one of the boxes, write in the capabilities that are well understood by a particular business stakeholder, then go to that stakeholder and validate your choices. Make sure that you have placed the correctly for that stakeholder’s particular business models. Note that very few stakeholders will have a valid opinion about capabilities that are NOT part of their particular business model, so don’t show capabilities that they don’t care about.

You will quickly discover that most folks agree on some things and disagree on some things. Where a single capability shows up in multiple businesses, one stakeholder may say that it needs high standardization, while another will say that the capability needs low standardization (== high flexibility). Take note of these disagreements. THEY ARE THE VALUE POINTS FOR BUSINESS ARCHITECTURE.

On everything you can get reasonable agreement on, go ahead and create a master table that has the capabilities differentiated in the manner above. That will probably be about 90-95% of your business capabilities in your taxonomy.

Step four is to make an “educated guess” about the operating model that your organization has. It’s a guess because most organizations are difficult to read and no one person will be able to answer your question about what the company as a whole looks like. Most of the time, you can start with the generalizations that Jeannie Ross made when describing the four operating models in her book “Enterprise Architecture As Strategy.” If there are a large number of capabilities in the “High Integration, High Standardization” box, you can suggest that your organization is a “Centralization” model. If, on the other hand, there are a large number in the “High Integration, Low Standardization” box, you can suggest that the organization is a Coordination model. This is the educated guess part because there is no good formula for making the guess. By this point, you will know a great deal about the organization so your guess is as good as your stakeholders.

Step five is to take a cut at your core diagram… Draw it out and then work with your stakeholders to get common understanding.

For each of the four styles of models, there are different styles of core diagrams. The centralization model tends to break out capabilities by functional area since there is very little (intentional) duplication. So it will be a diagram with a series of functional areas as boxes with the capabilities for each function listed in the boxes. Good idea to put the name of the person accountable for that business function in the title of the box. Lines between the boxes represent flows of information or value between them.

The Replication model is somewhat similar. There will be some functions that are owned by “corporate” while the rest are replicated into EACH of the operating units, so there will be two large “areas” on your diagram. The corporate area will have some functions with capabilities in them, and a single “replicated” area will have the remaining functions with capabilities in them. This is wildly valuable to business planners because they can get agreement among the leaders of each replicated unit about what each one of the is accountable to do and what they MUST depend on the corporate unit to do.

The collaboration model tends to be “hub and spoke” with the hub being the most integrated capabilities and the spokes being unique to each of the business models (or in some cases, small groups of business models that share a lot of capabilities). The lines tend to be information flow, not value flow. The capabilities in the spokes are usually duplicated between the different business units but they (should be) the capabilities that each business unit needs in order to differentiate itself or its products in the marketplace.

The diversification model is the most complex because the “corporate” unit tends to have a small number of core capabilities (often just financial ones) with each of the subsidiaries having a nearly complete and quite independent set of functions with massive duplication of capabilities across them.

I hope this gives you a good start in creating your core diagram.

Operational Resilience through Managing External Dependencies

by

These days, organizations are rarely self-contained. The challenge here is how to manage the dependencies your operations have on factors that are outside your control. The Open Group’s Dependency Modeling (O-DM) standard specifies how to construct a dependency model to manage risk and build trust over organizational dependencies between enterprises – and between operational divisions within a large organization. Continue reading →

Different Words Meant Different Things, Part 3

by

This is the final installment of a three-part series that discusses how our vocabulary affects the way we conceptualize Enterprise Architecture, Business Architecture and their relationship. To close, The Open Group’s Leonard Fehskens will consider the implications of a more inclusive concept of enterprise on the future of Enterprise Architecture. Continue reading →

Different Words Mean Different Things, Part 1

by

In part 1 of a three-part series, The Open Group Vice President of Skills and Capabilities Len Fehskens discusses how our vocabulary affects the way we conceptualize Enterprise Architecture, Business Architecture and their relationship. Continue reading →

Architecting for Secure Business Collaboration

by

The Open Group Framework for Secure Collaboration Oriented Architectures (O-SCOA) Guide provides system and security architects and designers with a blueprint specifying the requirements for secure design of enterprise architectures that support safe and secure operation, globally, over any unsecured network. Continue reading →