“New Now” Planning

In my last post I suggested that the planning of large transformation projects needs to focus more on the first step than on the end goal, because that first step, once taken, will be the “new now” – the reality with which the organization will have to work. I promised to try to explain how this might work in practice, so it here goes… Continue reading

#InfoArch – Post 1. Information Architecture – Our definition

Introduction Within all major industries — including automotive, banking, healthcare, energy, telecommunications, insurance, and government— organizations from around the world are beginning to understand the importance and tremendous value associated with ensuring the accuracy, consistency, and timeliness of their own information. To this end, companies are gaining a better appreciation for Enterprise Information Management and […]

Four principles – 2: There are no rights

What rights do we need to design for in enterprise-architecture? At the really big-picture scale? This is the third in a series of posts on principles for a sane society: Four principles for a sane society: Introduction Four principles: #1: There are no rules

Native EA Apps

Update: Native Apps Part II: A Hybrid App Every single web page out there, if you like, is like a computer. Tim Berners-Lee Modern web technologies (HTML5, CSS, Javascript) allow us to build advanced solutions. Although not that advanced, a service like EA Glossary is in fact just one single web page, i.e. one HTML5 document. …read more

Addressing the Multi-Dimensionality Challenge on Thinking of The Enterprise as a System

Last week I had the pleasure of attending and presenting at the Open Group conference in Newport Beach, California.  I find these conferences enlightening as I enjoyed the dialog with fellow professions who share similar point of views on the&nbsp…

Addressing the Multi-Dimensionality Challenge on Thinking of The Enterprise as a System

Last week I had the pleasure of attending and presenting at the Open Group conference in Newport Beach, California.  I find these conferences enlightening as I enjoyed the dialog with fellow professions who share similar point of views on the discipline of Enterprise Architecture.   I have made the following observations: We have a huge challenge in…

Enterprise Architecture and abstraction layers

I recently read John Gotze’s thoughts on the updated national enterprise architecture framework and its underlying meta-model published by the Danish Government Agency for Digitisation. The framework is named ‘OIO EA’ and has evolved over a number of years into the official national government architecture approach. In his critique, John highlights that the updated meta-model …read more

The chance that your car might be washed away is not the only…

The chance that your car might be washed away is not the only reason to avoid driving across a flooded road.

The greater danger is that the road under the flood waters has already been washed away.

How many large system projects fail because of unexpected dependencies or unknown conditions?

Visibility is a clear and immediate benefit of a mature EA practice. 

And remember, just because the road is going in the right direction – i.e., is aligned with your business – does not mean it’s at all safe.

Photo By Brian Stansberry (Own work) [CC-BY-3.0 (http://creativecommons.org/licenses/by/3.0)], via Wikimedia Commons

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

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.

Four principles – 1: There are no rules

What rules do we need in enterprise-architecture? At the really big-picture scale? This is the second in a series of posts on principles for a sane society: Four principles for a sane society: Introduction Four principles: #1: There are no rules – only