Tuesday, July 27, 2010 |

 You’re all familiar with the knuckle-dragging pre-human to bipedal homo sapiens series of silhouettes that looks like it first appeared in National Geographic (anyone remember?). But this time I’m using them to illustrate some of the major points on the upward curve of software evolution.

And while neither human evolution nor software advances in correctness are as linear or as easily charted as the graphic suggests there is a similarity between them where highlights from a particular tree become visible from a single point in time, like now and to me.

Starting with Structured Programming - this was a breakthrough in code maintainability where similar logic or logic related to similar data was modularized for easier understandability. Without such an approach if/then/else clauses spanned many pages, making a code base nearly impossible to debug in a timely manner much less to hand off to another developer.

Objects overcame the division between separating code by logic or by data by allowing the developer to combine them both into an object, a single entity.

While this was a revolution to those in the craft of writing code it only helped those writing code to understand their world better and outsiders were not usually part of the arrangement of objects, class diagrams and activity diagrams notwithstanding.

Services and processes were the first entities (in this tree) to be of concern outside the development community. They could be thought of as directly supporting the business. They could be socialized and discussed by subject matter experts and process owners. Although services could be placed in repositories and called by other services and SOAP vs. REST could be argued by the technology community these were sub-plots to what was going on. And what was going on? Software usage was mushrooming and becoming a management problem that wouldn’t go away.

In other words, software was experiencing catastrophic success.

In the late 90s and early 2000s the DoD came upon the concept of capability. Each branch seemed to have its own take on how to utilize the concept and in the current DoDAF capabilities have their place in the DoDAF meta-model.

I’m here to tell you that the story doesn’t stop there. While having a meta-model is critical to keeping your feet on the ground there’s a lot more to capabilities than that.

In short, we at SenseAgility Group, are offering a Capability Based Business Architecture course that draws its inspiration from such things as IEEE 1471, MIT Sloan’s Business Operating Model, UML, BPMN, Archimate, & TOGAF. This means that we provide, through a succinct capability lens, a way to connect architecture with business architecture on a cost and value basis. Not only that but we can connect process, organization and risk/security issues in the same way.

This allows management at any level to organize software and invest in it according to their strategic plan or even to develop a strategic plan using capability based analysis. That last idea, btw, is what the Capability Portfolio is all about.


Live Blogging from OpenGroup Boston - Jeanne Ross

Tuesday, July 20, 2010 |

Up first:  Jeanne Ross of MITSloan School of Business on Evolving EA from IT to Business

note:  I've been following her research since publication of "Enterprise Architecture As Strategy", since I've witnessed first-hand the consequences of Business Operating Model Mismatch (or BOMM for short).   Not surprisingly, there are many posts on this blog that discuss Business Operating Models and their impact to organizational vitality and stability.

"Architecture is a tough topic at a typical cocktail party."
"Architecture problems are not IT problems."
Why Architecture Matters:
  • Enterprise Architecture: the organizing logic for business process, data, and IT capabilities reflecting the integration and standardization requirements of the firm's operating model.
  • Agility:  the use of existing IT and business process capabilities to rapidly generate new business value while limiting costs and risks.
  • Many firms are not in a position to concern themselves with agility
    • Keeping the firm out of trouble (risks and costs)
    • Making the firm more competitive (NFP: more effective)
  • Architecture function cannot drive benefits if everyone isn't on board
Key question:  how can Architects sitting in IT get everyone in the business on board?
Going through the research on "EA as Strategy" and "IT Savvy"

My question on the maturity graph - the y axis supposedly measures "Strategic Business Value."  What is the definition of "Strategic Business Value?"  What are the components?  How can the points on this curve be quantified?  If Enterprise Architecture starts marketing to the business on the value of maturing from silos to business modularity, or points in between, these numbers will be needed to create a compelling and organizational context specific business case.

"Four Stages of business maturity - silos, local standardization, optimized core, and business modularity, and symptoms/capabilities of each
Commitment to IT:

  • - Strategic Choice Making - how will we use IT (and more importantly, what is the scope of IT)?
  • - Actionable Assessment - How will we keep on track?
  • - Working Smarter - How will we work digitally?
  • - Distinctive Digitization - What digital capabilities will we create & reuse"
Going through 7-11 Japan, Toyota Europe, and Campbells Soup examples.

@bmichelson's take: "#entarch is is mmm mmm good"

To end:

"If there are no business metrics, there is no business architecture.  Stop the train!"

Could not agree more.  This is why we include Metrics and Measurement capability as part of the Business Perspective in our Enterprise Architecture Capability Map.

Entrepreneur, Prepare! (or Beware)

Tuesday, July 6, 2010 |

I've had a few insights after helping businesses launch as we have over the past year.  First of these is about preparation.  When our clients talk to financing sources (Banks, VCs, Angels), one of the first comments is invariably about how well prepared they are.  It seems counterintuitive, and even strange, but it is apparently the majority that ask for money without being prepared and by that I mean a fully baked business plan, long and short term financials, and proposed valuations, etc.  That is suboptimal on multiple fronts -

  • Not preparing for investors and lenders lengthens the vetting process.  This is a common complaint on both sides of the deal, and is likely the most common cause of value loss in these transactions.
  • Then, there are few investors and lenders that won't automatically default to categorizing such request as coming from a "unserious" person.  From their point of view, there are really no mulligans for how busy the requestor is - there are many requests, and all they can assess is data in front of them.
  • If process moves forward, not understanding proposed valuation puts the requestor in a very vulnerable position.  To be sure, even CAPM is not a trivial calculation, much less Arbitrage based methods.  However, this is where the investing party can demand a much larger equity stake of the company than they should be entitled to based on cash flow projections, discount factors, and risk.  Without knowing the "base" from which to negotiate from makes for a difficult negotiation.

My philosophy in business has always been colored by Sun Tzu: "The general who wins the battle makes many calculations in his temple before the battle is fought."  That's not to say that we need to spend an inordinate amount of time in preparation - this is where Capability Based Approaches help.  As one of our clients noted recently, "it's like strapping a jet engine to my idea."


Capability Investment Management Revolution


Back in the early 1900s a concept called "Modern Management Practices" or "Self-Control" was all the rage.  Originally conceived at DuPont and General Motors it was a way for managers to have detailed control over employee tasks - because back then managers actually knew everything there was to know about the production line. Essentially, it was a process automation approach.  And it worked for over 50 years, until machine-based automation wasn't enough for competitive advantage.  Computers entered the work environment and we have been trying to figure how to cope with information automation and management ever since.

So from the 1950s on, several management models have attempted to harmonize information management with process management. The first of these was Deming's Total Quality Management (TQM).  It was greeted with such skepticism that he had to go to Japan to try it in practice. Drucker followed with "Management By Objectives" (MBO) in late 50s, which was essentially a rehash of Self-Control with a twist - rather than managing by task, the approach allowed for some creativity and knowledge to be used by giving employees objectives and letting them come up with optimal way to satisfy those objectives.

The 1980s brought a slew of management approaches.  Porter's "Strategic Management", a revival of TQM based on Deming's success with Japanese industries, and Cooper, Johnson, and Kaplan's "Activity Based Costing" (ABC).  The1990s brought Hammer, Davenport, and Short's "Business Process Reengineering" (BPR) plus Kaplan and Norton's "Balanced Scorecard".

All of these approaches, save Porter's "Strategic Management," are focused on how things get done. Most of them allow for a feedback loop for strategic decision making, but that's hardly enough for consistent practices in identifying, developing and defending their Sustainable Competitive Advantage (SCA) - the purpose of Porter's work.  Everyone provides ideas on strategic management, but inherently omits "how" information processing affects strategic decisions.  To be fair, this is consistent with a deterministic view of management, where causality rules the day.  And yet, if there's anything information processing has shown us in the past 50 years, it is that business is not deterministic.  Hence, entering the 21st century where velocity of information is approaching the speed of light and coherence of that information is questionable, correlating information to make the appropriate decisions has never been more challenging.  We see the effects of this in how often projects fail to deliver to expectations and continuous turmoil in strategy and planning functions like Enterprise Architecture and Portfolio Management.

So while the main challenge for Capability Based Management is to provide a consistent method for correlating diverse data to increase fidelity of information used in decision making, it will have an uphill climb without breaking the deterministic view of management that is so built into our business management school curricula.

Decoding Business/IT Unity - The Podcast


Great many thanks to the team at OMG for getting my Decoding Business/IT Unity Presentation through production and posting the podcast last week!  Listening to what I said 3 months ago and correlating it with a new book I just finished has given me a few new insights - a lot of which will be appearing on this blog over the next few months.  Special teaser on theme:  Complexity is an Illusion.