For those of us in the Enterprise Architecture, impressing the value of discipline on the world that is incentivized to ignore it, is par for the course.  Whether it's due to great expectations, unrealistic timelines, lack of coherent planning, or all of the above, ensuring and enabling others to follow a method or process with trust that success will not come from taking shortcuts is a Herculean task.

So when we transitioned to a Capability-Driven Startup Incubator model, we essentially doubled down on the belief that if done in a disciplined way, we can help entrepreneurs launch companies that are successful, profitable, and not hampered by capability debt (debt of suboptimal decisions made for expediency or based on incomplete information, or by wrong people in wrong positions.)  You'll see the results of that bet start appearing in the public light next quarter so you can judge whether our bet is paying off.

It is from a discipline perspective that I ran into a very curious piece on Chicago digital startup community that appeared in PandoDaily.  It centers around defining the "Midwest Mentality" of pragmatism, as follows:

Pragmatism is defined as dealing with issues on a practical level, rather than a theoretical one. What does this mean in the context of startups? Well, it means that there is no “let’s build a cool tool and then figure out the business model”. No. In fact, if you do that here, you don’t belong. That’s a plain fact that I have found very few people disagree with.

And while the author (Trevor Gilbert) goes on to provide both pros and cons of pragmatism, he spends the majority of the article blasting pragmatism in context of digital startups.  He delves into working hours, missing the point that amount of work doesn't usually correlate to success.  Those of us with kids don't just stop working once we go home - I see many of my married with kids counterparts firing up the laptop after their kids are in bed.  But we can debate whether parents working 9pm to midnight is more productive than their single counterparts spending that time having fun at a bar - either is simply anecdotal and should be taken with several grains of salt.  It'd just be nice if Trevor thought to research his arguments a bit more.

And in that failure of discipline, he makes and then fails to expound on the major point of why Chicago startup community is so different from Boston or Silicon Valley:

Without hot startups, you are left with the problem of attracting investment and talent with names observers don’t truly know.

Here Trevor inverts the causality in support of his argument.  That is shoddy at best, sensationalist at heart, and substandard thinking at worst.  The cause of few "hot startups" is not our pragmatism.  It's the fact that there is a "problem of attracting investment and talent with names observers don't truly know."

If Trevor actually listened to the Chicago VC community, their investment dollars usually go to people they have built a relationship with - over several years.  It's not that talent, intelligence, adaptability, and stick-to-it-itiveness of the idea don't play a role.  It's that in order to be rated on these measures, the prospective entrepreneur has to clear a very high barrier to entry of building a relationship with the prospective funders.  Perhaps it's a throwback to the old Chicago politics paradigm of "we don't want nobody nobody sent."  But perhaps it's not strictly a Chicago issue (here's a WSJ article bemoaning that fact nationwide), just more pronounced here.  Regardless of cause, this state of affairs limits our city to be the backwater of seed investment dollars.  Either way, I'm not sure that "Midwestern Mentality" has much to do with it.

AAB

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.

First posted on Built-In-Chicago 

I ran into a VC from NYC at a conference yesterday. He said he wanted to see why the Chicago VC market hardly registers on the map. While I wasn't sure what he was talking about yesterday, I went to WSJ VentureSource and found this map:

WSJ: VC Investments, 1st 6 months of 2011

Now I understand his point of view a bit more clearly, and this is really disappointing. Not that I would expect Chicago to be close to Silicon Valley, but this?

Area	Investment
San Francisco	$3.3b
San Jose	$2.2b
Boston	$1.9b
New York	$1.3b
Los Angeles	$900m
Washington DC	$582m
San Diego	$375m
Chicago	$296m

Really? Chicago has 5% as much innovation as that of Bay Area? 20% as much as that of Boston? 25% as much as that of New York? How can we close the gap?

AAB

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