1 year, 8 months ago

#NRF2018’s Focus On Customer-Associate Engagement

At the packed NRF Big Show #NRF2018 in New York last week, many retailers looked at vendors touting new tech, including AI, AR/VR, and more, all in the name of improving customer experiences. But most of those same retailers know that, before leaping i…

6 years, 8 months ago

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.

8 years, 7 months ago

Don't Let Your Architecture BRP…

My projects and architecture activities center around health care (care providers and health insurers) and state/federal government agencies. With health care reform is still in place at this moment in the US, there is plenty of architecture and implementation work…

8 years, 7 months ago

Don’t Let Your Architecture BRP…

My projects and architecture activities center around health care (care providers and health insurers) and state/federal government agencies. With health care reform is still in place at this moment in the US, there is plenty of architecture and implementation work…