Seemingly a lifetime ago (2009!), I shared how security concerns have to be "baked into" any cloud platform, as well as a simple set of capabilities to consider when addressing said security concerns.  Of course, information security is just one aspect of cloud readiness.  There are others, and today's post from Chris Curran's CIO Dashboard made me ponder a couple of lessons learned from our cloud platform adventures of the past 2 years.

What I tweeted in response to Chris is that cloud-readiness comes down to a simple question:  how robust is the middle tier of the system architecture?  Specifically, how easy is it to integrate and how well instrumented is it?  This can be problematic for most enterprise and SMB business applications.  Very few of these were created with the forethought that both small and large grained chunks of functionality could ever be exposed as standalone applications themselves - outside of the safety of corporate networks.  Add that integration and instrumentation are usually inadequate due to a combination of factors - project scoping/delays/failures, adoption of software design approaches that scorn architecture, and general lack of talent and experience at key positions - it is not surprising that Chris is advocating a comprehensive analysis of the total cost of moving to the cloud.

At the end of the day, lack of cloud readiness is a result of many factors and decisions that seemed sensible at the time to the decision makers.  But we are where we are - and not being able to make a move to the cloud places organizations at a competitive disadvantage.  That's not hot air - the difference between our platform using cloud-based services and not using cloud-based services is easily quantifiable.  I can't expose the internal operating ratios, but that difference can be measured in several orders of magnitude in operational run rate.

There's been a movement in Enterprise Architecture circles to talk about the vast amounts of technical debt that have been accumulated over the years in most organizations.  That technical debt grows with every decision that is made for expediency sake or with full ignorance (or worse, in spite) of supporting information.  And while I haven't yet found many receptive audiences for the concept of technical debt, perhaps the hard numbers that force many IT organizations "out of business" over the next few years will finally convince the software architecture community of just how spectacularly they have failed at their job.  And the total cost of moving internal applications to the cloud is just one of many quantifiable ways to measure that failure.

It's been 9 months since our last post.  That doesn't mean that we're no longer here, or that we're not thinking about these topics, or that we don't have anything more to say - those of you who know me realize that option is just about impossible!

As some of you may know, we spent 2011 transitioning from technology management consulting to a startup incubator.  That may sound strange - but the nice thing about having a comprehensive intellectual platform like CIMM is that is it allows for wholesale changes in business process with little impact.  

We've embarked on several projects with CIMM as our key stone.  Using Capability Based Business Architecture, we created a cloud-based business operating platform in 2011 that each of our projects can leverage to minimize their launch costs.  And as some of these projects launch (congrats to Everybodysafe.com to winning the race to the starting line) we'll be bringing you lessons learned on using our platform to create businesses from scratch.

I'm finalizing my presentation for Business Ecology Initiative's Optimization for Innovation conference slated for March 22nd in Washington DC.  Initially, I was approaching it as a humorous rejoinder on how to cope with taking the reigns of an organization one didn't have much knowledge of.  But life has a funny way of throwing curveballs, so here are some thoughts that I'll be delving quite deeply into in 2 weeks:

1. As I hinted at a few weeks ago, investment into succession management programs -  a laudable organizational investment into sustainable leadership - has evolved into a serious operational capability risk.  While competing capabilities were always a possibility in our model, this is the first real example where investment into one has a negative impact on others.
2. I had the opportunity to listen to Dr. Jeanne Ross of MITSloan CISR a couple of weeks back.  She made a lot of interesting points that will be expounded on in future posts, but the one that's relevant to the topic at hand came from a success story at PepsiCo.  I'll paraphrase - as she interviewed the chief change protagonist, one of the off-the-cuff comments was that a major contributing factor to PepsiCo's success in creating their Optimized Core was stability at the executive sponsor ranks throughout the process.  The quote was something along the lines of "I don't know what I would've done or would've happened if we didn't have that stability throughout the change process."
3. So that got me thinking.  I've personally gone through an executive sponsor change as the "face" of a major change program.  It's not an experience I'd like to repeat - nor have I heard of anyone in a similar position finding it a positive experience.  So instead of looking at this topic from the viewpoint of the new boss, perhaps the real need is to prepare the people who are running these programs and operational units with tools to minimize the impact of this operational capability risk.  

See you on the 22nd!

AAB

Several interesting points that deserve their own blog posts, so this is just a conversation starter:

- EA should not be inside of IT, and it's usual placement hampers both IT and its effectiveness.
- EA maturity is directly related to organizational performance, and can be built in discrete stages.
- Overall IT Budget increases by a factor of 50% in organizations that are in Stage 4 (Business Modularity) and business leaders love that because they get more per use and time to market increases that give them competitive advantage.
- One of the determining factors of EA-lead transformation success is stability in the executive ranks (yes, my presentation on this coming in a month, so stay tuned)
- Strategic Agility has a dependency on evidence-based management culture.  This culture cannot be built overnight, nor can it come from natural evolution.  It has to be enabled from both top and middle.
- There are three (3) key requirements to work smarter: Operational Intelligence Backbone (Competing on Analytics), Business Rules Management (BRM), and Organizational Development.
- Align business activities with IT - not IT with the business activities.  Otherwise you're trying to align the most static strategies with to the most dynamic.  Create a core - and then align things to that core.

Please discuss!

AAB

Bruce Silver, BPMN luminary, has recently posted a piece on BPMN and Business Architecture where, he says, “In the past year the ‘architects’ seem to have discovered BPMN.”  WIth his usual meticulous style he dissects the difference between a process and other notions such as capabilities and functions, terms that architects like to throw around in their paperwork.

He clearly distinguishes process as the “how,” which is what we, at SenseAgility, have been saying as well. Process diagrams, and BPMN diagrams in particular, are the proof behind a particular type of capability, namely the Business Capability. In our work we’ve found that there are specific types of acceptable proofs behind different types of capabilities.

Here’s a statement Bruce makes about typing or perhaps it is even about granularity by implication, “If you’re sorting things into boxes, it doesn’t matter so much if some boxes hold square pegs and others round holes. But when you want to assemble those boxes into a coherent unit, it would be easier if the pegs and holes all had the same shape.” To us this principle is exactly the same one we employ when naming capabilities. As mentioned above, capabilities are different types. You can tell they are different types by looking at the proof behind the capability. That is, what makes the capability a capability in the first place? Business Capabilities have processes behind them, maybe more than one, but at least one.

So what I’m saying here is that if you want to give a name to a capability you need to have something in mind besides appropriate wording. Just getting people to agree on words doesn’t cut it. Why? Because ultimately you need to be talking about something of value. If capabilities can’t be linked to something of value then you might be imagining capabilities in a vacuum.

Anyway, subscribe to Bruce’s excellent blog when you get a chance.