Cloud –hype or a lesson to learn about ongoing technology change

A while back the model was there was a market for just 10 mainframes worldwide, or so the quote goes.  The in order for a corporation to join the big boys, you needed your own.  Decades later I’ve the equivalent of a S/360 processing power in my pocket.  If one follows the technology generations: On-Prem. Mainframe; Department Minis; Timeshare; PCs; Client-Server; then Internet, Now Cloud. There is always a new technology on the horizon (e.g., quantum computing) that will solve the worlds problems and put the kids to bed on time or so the marketing hype goes.

I’m neither a fan-boy or luddite when it comes to new technology.  I believe I’m a pragmatist.  I’ve a set of simple rules when it comes to acquisition and holding onto technology:

  • Explore and examine, but do not commit till conditions point to such
  • When exploring the technology, examine both the technological aspects:
    • does it add new capabilities
    • Is it stable (mature enough, reliable enough, has enough market share to continue a reasonable lifespan)
  • and business application:
    • does that new capability add something to my business
      • Reach to customers or markets
      • Improve customer relationships
      • Allow me to do something new for customer or improve my operations
    • or reduce costs and risks

Which brings me to the latest R&D I’ve been conducting over the past few decades that fits into my larger research project of creating a CAD/CAM system for Enterprise Design, Construction, Operations, and  Remodeling.   That latest research has been all about the overlap between business and technology strategy.  This is something my mentor John Zachman had started decades ago.  By now I can imagine several people’s eyes rolling. “Zachman Framework!, that so yesterday…”  However, those that have seen the decades of methodology hype go by know that the Ontology expressed in the Framework still is relevant.  Its just not the “silver bullet” everyone wants.  It takes some work to understand that the views defined in the Framework are there for a reason: To understand the various aspects of an abstract entity, Enterprise, to be manifested.

Given the hype and technology priesthoods that have developed around various methodologies: TOGAF, DODAF, SAFe, BPMN, etc.. I will not enter into the fray, other than to say these all have some aspect of utility and all address some dimensions in the Zachman Framework. 

Back to Cloud and business/technology strategy:  As of late business models or various levels of business models (Campbell’s Operation Model Canvas**) are become more mature from decades ago and starting to reach across to technology or rather technology has been identified as an enabler to business strategy.  With that as an underpinning to this post.  I post the real question around Cloud and Cloud Hype:

The real issue is how or should you take advantage of such. If you’re just switching technology to “modernize” that’s fine.  If the cost of maintenance or business continuity risk due to end of life is a significant threat changing technologies is a simple model (i.e., you’re replacing you car because you can’t get anything more out of your Model T).  That does suggest however, it will be running business as usual.

That, in my opinion, is short sighted as few businesses are in an environment that enables that.  Today business as unusual is the norm.  There is so much volatility and change going on in the space we call enterprise that operating a business is now more an effort of managing complexity and change than executing a simple production line was twenty or thirty years ago.  As such prior to committing to such a change it behooves Executives to ask the questions beyond the easy just replace On-Premise with On-Cloud for a supposed cost saving, how will I exploit the technology to improve my business besides just keep it operating another day?  As well as ask what are the trade-offs I make with such choices:

  • Dependencies/Risks on a service provider
    • Will they be around tomorrow
    • Will the service change
    • Besides Security and Data Ownership, can I extract such to a new provider should I decide to
  • Will/Can I integrate a broad spectrum of services together (primary vendor and others) with moderate or less effort, or is it really a closed system
  • How long will it take to covert?  Will the conversion take more time than the technology is likely to be in place

The thing I tell my clients continually, there is no free lunch, there are always trader-offs.  Some immediately, Some during an event, and Some eventually (i.e., in the future).  It is up to your executive team, not the technology providers or operators within the company, to understand these implications and impacts.  -And if your team does not have the confidence in making these decisions get a Business – Technology Strategy Consulting firm to assist.  This is not a technology strategy consulting firm (i.e., how to install, configure, and operate), but one that focuses on how-to use the technology for business as well as what are its implications to the business.

**full disclosure I’m working with Andrew Campbell on a tool suite to evaluate Operating Models similar to the evaluation tool suite I built for the Business Model Canvas community

Started Enterprise Portfolio Management CMM white paper last night.  Expect this will become a finished chapter in Enterprise Design and Engineering book in progress.  Presently collating and organizing materials from all the engagements and methods I’ve produced for corporations over the years into a cohesive practice guide.  This will be a companion guide to the tools suite I am working on to release some time end of year.

enterprise-portfolio-management-white-paper

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

Internet of Things

During yesterday’s drive home and this morning’s drive into work I considered the latest Hype-cycle meme “IoT”, the Internet of Things.  That magical connection of every device to…  While we’ve had IoT in many forms prior consider X10 which many a RadioShack customer “wired” their house with, then PowerBus, etc.  Then as microcomputers truly became ubiquitous, home started getting wired for TCP/IP and later WiFi.  Now the amount of Wifi Hotspots around businesses and homes is staggering.  At an apartment a few years ago I was amazed to find no less than twenty-three private networks within range, no doubt all connecting various devices beyond a PC and providing services such as video and audio media.

Now as the term “IoT” comes into play I wonder if this and the “app” crazy has created the ecosystem that is the digital equivalent of what we all complain about airlines and hotels these days?  a la carte pricing and thereby cause the consumer and business to be the systems integrator.  The question become does “IoT”, “App Stores” and consumption economics become the perfect storm to devalue Information Technology and the complexity involved in integration.

I as this questions as more business executives question the value of enterprise and other technology architectures while in the same breath can’t understand why the pieces don’t fit together easily in just a flew clicks.  I wonder if that CxO’s car stops dead in the desert out of range of a cell tower will her or she be lost forever, given the likely inability to fix the technology they’ve asked for and become dependent upon.   About to decades ago and reprised the thought a few years ago, that one day businesses are likely to fail due to technology failure.  As this decade reaches the halfway point, I see that risk increasing beyond the obvious threat of hackers.

Methods: Designing a new Service

Had a great brainstorming session yesterday with a colleague discussing how to apply DSM techniques to the Service Design activities we’re involved in. [Going to have to update my methods PowerPoint again]  Came up with using DSM to identify and cluster functions across various customer requirements and then a simple prioritization using Risk DSM and Business Impact [ Risk * Business Value = Priority ]

Brainstorming DSM

Clustering activity is initially based on common functions. These are later categorized into one or more basic causes using Fishbone (Iishikawa) diagraming and 5 whys:  Capability, Capacity, Schedule, and other.  The context is total throughput (i.e., “The Goal” ).  This sets the context to prioritize which areas to address first.

 

Afterwards I when to my whiteboard to draft a model of the service I’m working on using Osterwalder’s Business Model Canvas.  Once I summarized the Business Process models I created before and extracted key components, it became obvious that the context needed to be changed.  The business in a business model context yielded some strange relationship issues.  Once internal supplying and receiving groups became Key Partners everything snapped to the grid perfectly, even then cost structure and revenue stream categories which are often hard to identify in internal business models: especially in IT where chargeback is often applied inconsistently.

Business Model Canvas

Modern IT Portfolio Management: Risk: System Definition

System Definitional Risk

One of the serious risks in Architect side is system definition. This is partitioned into completeness(e.g., maturity level [none to integrated], Validation level [none, author’s bench check……Simulation of requirements], and requirements freshness (i.e., things change, was what was needed specified and validated too long ago….).