Business Architecture

There is a lot of “Architecture” out there in the enterprise world?  It seems that the title ARCHITECT once held a lot of cachet.  You’d find someone titled or a book titled with the term architect in it almost everywhere.  However, during my most recent deep dive into the term applied almost all –IMHO– were not architects but designers and in many cases project managers.  I reached this conclusion based upon the definition I used to define architecture.  That definition has as it foundation the understanding of the components, interactions and uses of such used to create a desired entity.  That entity can be as concrete as a house or as abstract as an enterprise.  Which has led me to an interesting linguistic puzzle:  In many organizations and associations there has been a stated difference between an Enterprise and a Business architect.  Yet isn’t the definition of enterprise a business?  So rightly so shouldn’t an enterprise architect be a business architect?

With that puzzle aside, I again started to ponder my activities around Portfolio Management.  Much of what I’ve seen and experienced in large corporations in regard to Portfolio Management has been around economic prioritization.  That is “We has a fixed budget, how can we spend it all to receive the greatest return on each individual investment?”  This inevitably results in a effort to stack rank projects by simple ROI or in the case of IT projects KLO (keep the lights on).

Most recently I watched several organization build up a portfolios (aka backlogs) of projects to be prioritized and executed.  Many of these projects were classified as either KLO or Innovation projects which were given the highest priorities depending upon who in executive leadership was overseeing.  However, deeper investigation revealed that these where neither, but rather what I would call optimization projects (see portfolio management project portfolios).  While not a bad thing doing such gamesmanship results the enterprise as a whole not achieving the optimum return on investment strategy.  That is to say senior leadership has developed a strategy and middle to lower management, though well meaning, compromises achievement of such through their efforts of local optimization.

The way out of such conundrums is not having senior leadership make every investment decision down to the smallest detail though.  My belief is the best way to ensure investment optimization for the enterprise is to make the business architecture explicit and develop a consistent means to determine alignment, interdependency, and priority of current and future desired states.  Though looking at the existing enterprise’s state as a whole — what needs to say the same, what needs to change and when– an optimum path to an uncertain future can be charted.

The problem with such an approach is that it is often looked upon as complicated, thus is rejected out of had as lately the management trend is make things simple.  Which is rather ironic given we are in an time of multiple priorities and the second generation of the information age.  Such thinking is both comical and disturbing, given that many high tech companies are pushing products for Business Intelligence and Analytics to gain actionable insights yet they are still managing their own investments with nothing more than glorified spreadsheets.  Maybe I should not be so critical of the state of industry, given how long it has taken other engineering and design disciplines to mature into well understood principles to be applied.

In either event I’m now about an eight (real swag) through defining a comprehensive enterprise design methodology and associated curriculum for the book.  In architect-speak, I’ve laid out the rough framework and have started construction/acquisition of components for the methodology.  Two moths in, I may have to push back my anticipated book completion date.  One the positive side my employers will gain the benefit of this research and hopefully be able to apply it to their advantage.

 

Enterprise Portfolio Management

Updated the CMM and Capabilities Roadmap yesterday still have a few more items to add.  The roadmap is slowly coming into shape.  Hope to have presentation and tools ready by February conference

Modern IT Portfolio Management CMM

Like the original CMM this version for Portfolio Management has 5 levels.  Taking a page from the CMMI work I did in the Marketing Domain for IBM/Samsung, et al. It will contain an assessment tool to help enterprises do it themselves.

I’ve been developing a CMMI for Enterprises Architecture similar to the Software CMMI.  Enterprise Portfolio Management will be the first subsection of the EA CMMI which will be part of the Structure in Threes book in works. Modern IT Portfolio Management CMM Capabilities

Modern Enterprise Portfolio Management

Portfolio Management capabilities roadmap (initial) from last night’s brainstorming.  Planning (aspirational) to have Modern Enterprise Portfolio Management materials ready by February for a possible seminar at my home office over a holiday weekend.  The big question(s) will be if any of my colleagues and followers will be: 1) interested in attending a focused seminar, 2) willing to take the trek ~60 miles south of Seattle for a 1 to 2 day seminar.

 

 

Enterprise Portfolio Management CMM Roadmap

The nice thing about this research is I can leverage it as source materials for current projects I’m doing at work and for internal technical conferences.

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.

Business Model Enablement

One of the problems with Enterprise Portfolio Management (EPM) is its’ limited focus.  EPM to a large extent has been dominated by technocrats that act as though the entire enterprise is populated primarily by hardware and software; that is people exist to serve hardware and software needs rather than the reverse.

One can hardly blame management for this perspective and behavior when you consider the management systems in place such as financial systems have not evolved much since the middle ages.  Financial systems are “thing” based, listing such artifacts as depreciable assets.  While executives give lip service with such fraises as “People are our most important asset”, the majority of systems account for people as liabilities. When was the last time you saw a balance sheet listing the value of the people employed within the corporation?  This seems rather odd considering H/W and S/W requires people and their skill and knowledge to operate, maintain, and gain benefit from these other assets.

This brings me back to business models, currently the rage within executive and VC circles.  In the Business Model Canvas activities and resources hold a key position.  Its though these two components that value is realized as per the company’s value proposition.  Yet often neither the activity or resources boxes account for the people component –expect as either partners to engage with or customers to engage with.

Yesterday’s R&D activities has me investigating corporate capabilities and the associated competencies of people that enable these capabilities which are used to enable the business model.  Several years ago I developed a competency model that was associated with the process activities for a major function within corporations.  I see revisiting that work in light of business models will likely produce the alignment between people, portfolio, and business model that I’m looking to address in this round of R&D.

Benefits Realization

Been a bit busy stoking the home fires of late.  Attended COFES, amazing conversations as usual.  This month I’ve been focused on several areas of applied business architecture research.  IT Portfolio Management, Benefits Management, and Complexity Management.  All three are related to my Structure in Threes project.

  • I continue to develop the portfolio model section by section along with a working prototype.  Started considering the technology and system to offer to the market.
  • Benefits Management this month is really a parallel track, both R&D for ensuring a portfolio action supports Enterprise Goals as well as applied practice for the projects I’m working on at Microsoft.  The past few weeks I’ve been creating a Benefits Dependency Network for one of the subprojects.  I’ll be reviewing and revising that today with stakeholders as well as creating a draft Benefits Management Plan to help ensure the initiatives realize the promised benefits.  Part of that will be a Results Chain Contribution Matrix, a Benefits Distribution Matrix, and a Stakeholder Management plan.  Most of these artifacts I’ll recommend to my group for future projects
  • Complexity Management R&D is part of the BPR/M activities at work as well as Portfolio Management R&D.  Had a great discussion with Dr. Jacek Marczyk discussion elements of complexity.  We’ll have lots more to discuss.  I like his high level model:  Structure Elements x Uncertainty = Complexity.    I had previously separated Uncertainty from the equations I was developing:  Business Process Complexity =  {Information Complexity} x {Activity Complexity} using BPMN models as the base to calculate each factor.  As of yesterday I revised calculations from a standard node count bases to also include network linkages between nodes in each factor.   Later this week I’ll look at how I include Dr. Marczyk’s perspective of accounting for uncertainty.  I think I may also expand on that and use some of Courtney, Day, Schoemaker, and Primozic research into risk and uncertainty.  They’ve a lot of good materials that could apply to the problem space.

Structure in Threes: Building vs Planning

One of the problems systemic to the design and planning world is the often famous quote:  “Its done its just a small matter or implementation or programming or etc.”  All too often I’ve seen designers or planner consider the job done once the design is finished.  However, there is often a lot of work to get it accomplished; even it there are not changes to the design.  This got me thinking about the terminology used in regard to projects.  To me implementation take is a larger concept than just deployment which seems to be the typical thoughts around projects, especially in IT.  “The application has been installed we’re done”.  True implementation carries with it both deployment and adoption, anything less is just dumping.

The proposed remedy to this is to have adoption KPIs included in project metrics, not just development cost and schedule.  This would foster a greater concern that what is built is actually used.