Structure in Threes: Business Design and Reengineering

The last round of brainstorming tightened up my thinking around the methodology.  Like all engineering endeavors I needed to identify the beginning point for creating the enterprise.  Most of the business model approaches are just that.  They document the existing and while that is necessary, is that sufficient?  When I’ve attended workshops focused on business models, often it ends up around optimization rather than innovation.  The strategy and planning methodology I devised and fielded for other corporations was purposely limited, because at that time these corporation’s business models were deemed untouchable.  Even though several people could see its useful life was coming to an end.  Secondly, reengineering a business model it difficult for most in management positions…their mentality is around optimizing the status quo.  Not a blame, it how they were successful and how they are managed in most corporations today.

The brainstorm I had the other day was along the lines I had decades ago when I suggested a practice that would design and build corporations custom for an entrepreneur.  Thus one has to look at what that means.  What would be the design parameters used in doing such.  The past month I came to the conclusion that businesses should be designed around the customer rather than businesses trying to find customers around them.  That insight brought me to using Peter Mark’s (Design Insight) tool Customer$APPEALS (C$A) to determine the design parameters for the “product” I’m building; an enterprise.

With C$A as a base one can use that to weight investment is the various aspects of the business model and value chain the enterprise participates in.  With that as the starting point my methodology has evolved to the following:

Business Model Design -bks (2)

As of this positing I’ve tested this approach in two reengineering project that look to be successful and expect to do another pilot at another two corporations: one already in process and looking for another to pilot.  This “methodology model” will be one of several “views” in Structure in Threes” book and workshops I’m developing in spare time.  Expecting to have first workshop ready by summer.

Age of the App

Rogers and Moore’s customer adoption curves illustrate the results of several factors in apparent opposition; Value and Risk.  This two primary factors have been used to explain customer purchasing behavior as well as clustering customers into groups based upon purchasing time within a product’s lifecycle.  These simple models, which have proven useful to traditional marketing and sales organizations, but may need to be adapted to today’s new market dynamics.

Markets are becoming saturated with feature-rich products that promise value at the end of long implementation and adoption curves.  This had placed the majority of revenue in vendors pockets while placing the majority of risk in customers hands.  However, with the introduction of cloud and other same units of functionality such as smart phone apps, customers are rethinking purchases and demanding value capture for purchase much earlier, almost immediately upon purchase.  This shifting dynamic is requiring companies to rethink new revenue models based upon consumption economics.  This places more risk upon developer as the majority of revenue is generated through utilization charges not a single purchase, but has the potential to create a longer and more staple revenue stream over time.  This concept was introduced by Chris Anderson’s book The Long Tail.

This suggests that businesses will need to rethink how products are produced and adoption encouraged.  No longer can a vendor rely on a long list of features to attract and retain a consumer base.  Vendors will need to focus more on the value customers receive easily which suggests an increase focus on customer experience as Pine and Gilmore suggested in their book.  Making customer experience a primary design consideration infers a new way of thinking; an outside in design approach as advocated by UX gurus Alan Cooper and Bill Buxton.  This promises to be a more radical shift in software development than switching to Agile development.   But the signs are clear, the age of the App has come and vendors that wish to thrive in the market will learn how to capitalize on this approach and trend.

 

Structure in Threes: puzzle pieces

The last couple of methods –for the design and reengineering businesses –fell into place last night as I was walking through an internal presentation deck for a conference my team and I are presenting at.  Expect to start harvesting blog and presentation materials for book this coming month.  Interesting coincidence that book writing effort kicks off this coming month along with other life events.

The two additional methods will focus upon measuring the impact of the changes to the business model.  In Stafford Beer VSM visualizations, a system two and three dashboards.

As I continue to explain the design practice, I’m seeing another set of practice methods surface.  I’m a strong advocate of whiteboard usage in meetings and think SurfaceHub will enhance user experience once it becomes adopted in meeting rooms as standard equipment –I can see it replacing whiteboards and can’t wait to have four in my home office.  Added to that approach for collaborative efforts is a variation of TED Talks.  I think the process of explaining an idea in constrained time and answering questions helps sharpen the idea, as the questions force one to think through aspects of the idea that were fuzzy or ignored before.  I’ll have to prototype/pilot this concept next team meeting.

Structure in Threes: Control Systems

Started rereading materials around control theory and systems.  Much of current texts focus around electromechanical models of control systems.  However, I’m seeing strong affinity to organizations controls.  I’m seeing Stafford Beers work strongly aligns with those models of having operations, management, regulator/coordination structures, the environment and metric/measurement systems as the basis for a simpler servomechanism like model:  Environment, Operation, Management Control/adjuster, Sensor/metric device.  The questions then become whether open-loop or closed loop systems

Is Enterprise Architecture Completely Broken?

IASA Question Is Enterprise Architecture Completely Broken?

EA –that is credited to John Zachman– originally was “A framework for information systems architecture” a tool for MIS (aka IT) to “design” the components needed to support business objectives.  This was an evolution from a former methodology “BSP”  Business System Planning –also from IBM– which provide information to MIS directors and Business Executives to plan budgets/investments.  Later this budget prioritization was advanced by Parker-Benson in BEAM (refer to Information Economics).  EA roles became split into two camps:  Budgeting and Design.  The problems arise in that both roles forgot that the architecture role was that of facilitator rather than decision-maker and the primary stakeholders don’t have dialogs with these role holders typically.  This leaves rise to EAs creating visions and actions to create local optimizations.

Of course it is not too often that EAs are placed in a position that has the exposure and influence necessary to fulfill the role’s perceived charter.  Thus often EAs are glamorized programmers or software engineers granted the title after years of hard work in their domain by HR.  This gives them the title but not the scope or enterprise orientation.

More impactful to that position of influence; what CEO, COO or other CxO would grant that power to a non-executive.  While HR has toyed with titles such as CTO and CIO, the role of Chief Architect for enterprise has yet to be established in any meaningful way and has challengers to that title.  Books like “CFO, Architect of the business” are popular fair in the book trade.   And why would a COB/CEO/COO create such a role if they feel their role should be that, even if they don’t have the necessary architecture skills -after all they climbed to the top and are thus “entitled” to wear that crown.   However, it then gets back to a view of what an architect does/is.  Two schools or architecture: Architect as Decision-Maker, Architect as Facilitator/Advisor of Stakeholder’s Vision.

If one looks at chief design roles in other disciplines which have had more time to mature you’ll discover that such roles take years to develop an understanding beyond the mechanics of the discipline and how it fits in context beyond just building something.  This the senior role-holder must have a broader background than just Agile Development, DFD modeling, etc. and needs to step out into understanding the enterprise as a living organism. My recommendation is to study the Cybernetic Hierarchy in General Systems Theory to get beyond “Frameworks” and “Clockworks” through Adaptive/Dynamic Systems to Transcendental Systems.  These later types of systems capture more than frameworks do.  However with increases of information, increased thinking time is required to understand such data; something executives are in short supply of these days.

Parallel tracks: Skills transfer at work for colleagues and Structure in Threes book

Started a skills transfer series at work yesterday “Methods in Minutes” with the idea of creating short presentations on Enterprise/Business Architecture and Management Consulting techniques I’ve collected or created over the years.  Originally, I was going to collate about a dozen or so into a single methodology presentation.  However, after coming to the insight that people’s attention span today has gotten much shorter in direct correlation to the time horizon on which they work –that is many colleagues are focusing on getting just today’s stuff done or at best what’s on deck for the week– decided to just create a catalog of methods at their finger tips.  I’ll assemble them later into a IT Management Methodology later as the goal is to help colleagues and team-mate be productive NOW.

Sent out first method draft along with question “would this be useful” to the WW Architecture Community at Microsoft.  Got a resounding “yes” as well as an excellent suggestion to post these in a share or Office365 site rather than distribute via DLs or Yammer.  Looks to be a busy next year as I create and fill the catalog.

 

Structure in Threes: Metrics and Measurements

Spent the last few weeks divided between multiple projects and goals.  However, that gave me time to think about the topic of measurements.  Often in the IT field I see it being a great effort used to prove value or performance that ultimately has as its goal justifying existence.  When I hear about a new metrics initiative in most organizations it seems to boil down to how can we show with numbers that we’re meeting our targets.  All too often I think back to the radio show “The Prairie Home Companion” The closing words of the monologue are “Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average.”

This leads me to believe either we’ve set the bar too low or we’re measuring the wrong things.  About ten years ago I was at a senior leadership meeting at one of the well know technology powerhouses.  The one of the senior executives had, by edict, required a “serious” effort to measure performance.  The problem occurred not with the desire to measure, but the implementation of such.  There was no goal, other than measuring.  Thus each division, sub-division, unit, etc. identify metrics to report on.  In total over 1000 individual metrics of which cost the corporation lots of headcount to capture, collate, massage, and report at leadership meetings.  When asked if any of the these metrics were used to manage the organization or inform executives to make better decisions. I saw a lot of staring at shoes by people.  I asked why measure things if you’re not going to use the measurements to inform your decisions and directions; more shoe examinations.  Needless to say I was not invited back to a senior leadership meeting for a while.

Fast forward a few years later, the corporation is not doing as well as it once was and IT budgets are under fire.  I was brought back by a new leadership team; under cover.  That is I would dial in unadvertised and then consult to select members of the leadership team regarding my impressions and insights.  I think I was given this opportunity because during the previous incident I had predicted a scenario of what would happen to the IT org under its present course.  It was not a feat of great insight, it was merely a matter of connecting the dots. In either event I spent time with them, not specifically telling them what or how to measure, but why?  The old maxim “you get the behavior you measure” I’ve found almost true.  Often people measure what makes them look best.  Metrics are often tied to performance rewards.  This often eliminates these from being diagnostic tools.  This a little like the joke about the airplane captain announcing  on the PA system:  “I have bad new and good news.  The bad news is we’re lost. The good news is we’re making great time.”   Eventually there will be a crash.

Which brings me back to the metrics and measurements discussion.  Establishing a measurement program, one should first identify the strategic goals and objectives of the organization, then create metrics around those.  Next identify Key Performance Indicators (KPIs) that support those goals and objectives.  I look at KPIs a little differently than most I guess.  I think the label says it all these are “indicators” of performance, not the actual performance.  These are sort of like road sides telling you your goal is 100 miles ahead, then 50 miles, etc. and your speedometer it indicating 50 miles an hour.  Together these KPIs help you determine if you’re on the right path and operating at the right levels of efficiency and effectiveness.

Which again gets back to a metrics program.  A useful program has a mixture of “strategic” and “operational” metrics.  The strategic metrics tell you where your going, the operational metrics support you in letting you know you’re making progress towards getting to your goal with your resources.

Follow

Get every new post delivered to your Inbox.

Join 463 other followers