EA and Business Transformation

A respected colleague of mine posted today a small opinion piece on LinkedIn “Enterprise Architecture (EA) Is Not Business Transformation”  His post positions is that Enterprise Architecture is not about Business Transformation.  While I respect his opinion, this highlights the division that has yet to be resolved within the community I’ll state as best I can here.  There are two schools –well likely a few more– of thought as to what Enterprise Architecture is.  This may be because of its origin, coming from the information technology arena.

First opinion: EA is about design of information infrastructure of an Enterprise.  This sets the boundaries clearly at only those elements that are directly connected to or implemented in computer technology.  As such activities are then focused around selecting, designing technology implementations.  While this is the common activity and focus of many EA and EA associations, I would put forward that to call that “Architecting the Enterprise” is a bit of an overstatement.  In this role to add another metaphor one is acting more as an Information Systems Design & Manufacturing Engineer or Electrician.  The enterprise is already been architected one is just wiring the framed out house (Enterprise).  In such case, an EA’s role in transformation is just planning for swapping out of one technology for another: on Mainframe to Client -Server, Premise to Cloud, etc. 

Second opinion: EA spans the entire scope of the design and/or remodeling (aka Transformation) of an enterprise.  Here several issues rise.  

• Has an EA been trained on Finance, Organizational Design, Business Models, etc.
• Does an EA have the charter in their specific organization to work on such domains
• Is the EA reporting to the right governance body to work effectively on designing the enterprise — if you’re an architect who is your client and what is their design brief

Here is where I see many EAs:

1. Shout they’re not reporting to the right level within the organization
2. Restate their belief in the first opinion of EA’s design boundaries
3. Profess that Business Models, Organization Structure, Financial Structure and the like are not part of EA

To the last  point I’ll respond continuing Architecture the metaphor.  If one is to design a house, you don’t put out a floor plan or electrical plan by itself and call it job done.  There are a whole host of other areas to design; Plumbing, Roof , Foundation, etc.  In the design of an enterprise these would include Business Models, Organization Structure, Financial Structure, and other domains.   Does not mean that EA is domed to failure.  Not at all.

Let’s consider the case not of designing a house, but of designing a skyscraper or a city.  One architect is not likely to be designing the entire complex.  There are other “architects” working on specific domains and at specific levels of granularity.  So too is it in Enterprise Architecture.  

What this means is acknowledging that other expertise is required to design the enterprise and forming a design team to include these.  The implication of such is establishing partnerships within the functional organizations such that the business and operating models created within the executive suite are accessible to you and informed to them, same as organizational models & competency inventories, financial models, etc.  When such occurs whether formally or informally EA functions at an Enterprise Design level rather than a subcomponent design level.             

            

Strategic Planning vs. Strategic Plans

Spent last week in my first Enterprise Leadership Team strategic planning onsite meeting.  It was one of the better if not best strategic planning sessions I’ve participated in.  Rather than focusing on the two extremes –what can be do now to address some mess — or — pie in the sky dreams that have no basis in reality or likely to be realized– the session focused on reviewing where they were, why and what the vision of the business is to be.  As we covered what others may mistakenly consider trivial issues in sequence, you could see how these decisions narrowed down options to a laser focus as we at the end of this sequenced redefined or rather clarified what inherently knew was the business design’s skeleton.  While there is still much work to be accomplished on this, the skeleton provides the supporting scaffolding to successfully build out.

Strategic Planning and Strategic Plans are all well and good until the touch the reality of engagement.  What made the past weeks activities worth the effort were the last two days of the onsite.  With knowledge of where we want to be and where we are, we started deployment planning.  This is appears to be the fatal flaw in almost all the strategic planning sessions I’ve attended in the US.  Without planning how to deploy the plan, strategic planning results in pounds of paper and dilutions.  This seems obvious but somehow often gets overlooked.

One could say that’s because the strategic planning activity is designed that way. Or because there are no tools to translate strategic plans into actions.  However, both assertions are false.  Whether its because strategic planners don’t wish to get involved in deployment or as software designers often say small matter of programming 😉 or they are unaware of intellectual tools to assist, I find it more attitude that capability.  If I was to draw a parallel.  Design Engineering is often viewed as more glamorous and desirable that manufacturing Engineering, though its the later that can make or break a company.

With that said I’ll point to several approaches I’ve used, when I’ve been able to make the case to actually plan out implementing a strategic plan:  Hoshin Planning, Results Chain (DMR Consulting), Benefits Dependency Network (Cranfield), Strategic Capabilities Network (IBM), and Elyon Strategies own planning methodology.   My preferred methods are Hoshin Planning and Elyon’s as both focus on alignment to the strategic goals and a sequence of activities that logically contribute to achievement of the goal.  As I write this post I’m thinking of how-to merge Hoshin, Results Chain, and Elyon’s methodology as each as a strong point but a small gap that the other methods address well.

 

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

Saving your way to Bankruptcy

How often have you hear “Honey I bought it on sale and saved us a ton of money”? Really? Did at the end of the month you could see your bank balance increase? Often, we hear similar words inside an enterprise. We’ll saved 1000 man-hours with this new project.   Can you really save man-hours? I’ve not seen any place where time could be saved, much less get paid interest on it.

So, if these questions seem logical, why do we continually hear internally and from vendors about all the time savings? Possibly because emotionally we all like the idea of bargains and savings. The problem becomes that savings is not always savings.

Several years ago, I help develop an economic justification methodology specifically for my employer. As I had done this previously for other employers it wasn’t a large stretch if all they wanted was a standard ROI procedure.   I had brought up to management building an business case on time savings would have little value as CFOs and other management would know time saving is not economic benefit unless you do something with it or avoid having to get more resources to accomplish the goal.

The simple examples: I could automate a process using technology “saving” one hour a day per person. If I can defer hiring additional resources (cost) to accomplish a goal for a smaller investment in the technology, then I’ve actually saved money. If, however, I “save” one hour per day of staff time and nothing is done with that time, then I’ve actually lost money. If I continue to save time and money this way, I’ll be bankrupt in no time.

My advice for avoiding such a problem is while in the planning phases of a new initiative consider what you’ll be doing with the savings. Will the staff be able to effectively use that additional hour a day? This could be getting out one more proposal to a potential client, exchanging knowledge between peers, or any number of other activities. The key here is to have a plan on how that savings is to be used.

Is Enterprise Architecture Completely Broken?

IASA Question Is Enterprise Architecture Completely Broken?

EA –that is credited to John Zachman– originally was “A framework for information systems architecture” a tool for MIS (aka IT) to “design” the components needed to support business objectives.  This was an evolution from a former methodology “BSP”  Business System Planning –also from IBM– which provide information to MIS directors and Business Executives to plan budgets/investments.  Later this budget prioritization was advanced by Parker-Benson in BEAM (refer to Information Economics).  EA roles became split into two camps:  Budgeting and Design.  The problems arise in that both roles forgot that the architecture role was that of facilitator rather than decision-maker and the primary stakeholders don’t have dialogs with these role holders typically.  This leaves rise to EAs creating visions and actions to create local optimizations.

Of course it is not too often that EAs are placed in a position that has the exposure and influence necessary to fulfill the role’s perceived charter.  Thus often EAs are glamorized programmers or software engineers granted the title after years of hard work in their domain by HR.  This gives them the title but not the scope or enterprise orientation.

More impactful to that position of influence; what CEO, COO or other CxO would grant that power to a non-executive.  While HR has toyed with titles such as CTO and CIO, the role of Chief Architect for enterprise has yet to be established in any meaningful way and has challengers to that title.  Books like “CFO, Architect of the business” are popular fair in the book trade.   And why would a COB/CEO/COO create such a role if they feel their role should be that, even if they don’t have the necessary architecture skills -after all they climbed to the top and are thus “entitled” to wear that crown.   However, it then gets back to a view of what an architect does/is.  Two schools or architecture: Architect as Decision-Maker, Architect as Facilitator/Advisor of Stakeholder’s Vision.

If one looks at chief design roles in other disciplines which have had more time to mature you’ll discover that such roles take years to develop an understanding beyond the mechanics of the discipline and how it fits in context beyond just building something.  This the senior role-holder must have a broader background than just Agile Development, DFD modeling, etc. and needs to step out into understanding the enterprise as a living organism. My recommendation is to study the Cybernetic Hierarchy in General Systems Theory to get beyond “Frameworks” and “Clockworks” through Adaptive/Dynamic Systems to Transcendental Systems.  These later types of systems capture more than frameworks do.  However with increases of information, increased thinking time is required to understand such data; something executives are in short supply of these days.

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 ]

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.

Today’s Applied Research Agenda

Today’s agenda: R&D around Capacity Management for Services and Processes.  My presentation on metrics and measurement for processes went well, but I know risk and capacity management are a significant lack in this field.  Somehow everyone has gotten the opinion that Moore’s Law will bail them out…that hope is what the other engineering disciplines know now leads to unsustainability.  Received old book I ordered from Amazon Market [Computer Systems Performance Modeling, 1981 –Sauer]   that covered some of this in regards to computer systems.  Coupled with Meadows Limits to Growth (Systems Dynamics that Forrester introduced) I believe I can develop an approach to monitor, measure, and manage processes in more than a reactive way currently the industry norm.  While it will not likely be Nobel Prize winning stuff, I think it will help make Microsoft more competitive and responsive to customer needs     

Working Insights: Process Analysis presentation creation and the movies

Finished my presentation deck for Wednesday’s Business Architect call, sent it out to my manager & colleague, and other friends for comments.  The topic is business process analysis methods.  Its a short 20 minute presentation on the benefits and some methods of value for analyzing processes.  During developing I rediscovered what I already knew: Difficult to compress 2 hours of material into less than 20 minutes.  Makes me truly appreciate movie editors and directors…it take a lot of skill to cut things down to the bare minimum and no more.

Which has me reconsider my thoughts around BPR/M compliments I get in the form: “I’ve never seen anyone but you be able to diagram a process on the fly while we’re discussing it” or “How can you trim these processes down so well that there are minimum steps and each one contributes real value so easily?”  Often I just smile and say thank you, but really don’t think much of it its just what I do.  But I guess its because I’ve spent years honing my craft like editors and movie directors learning how to cut away what’s non necessary to the accomplish the job; in once case telling a story and in mine making a highly efficient and effective process for an enterprise.  I’m sure by now my colleague Sarah is smiling, nodding her head, and saying of course.

Structure in Threes: IT Business Models

Early

Yesterday on the way back from client’s site I started pondering the intersection of Service Quality, Brand Value, and Business Models with regard to Information Technology.  Traditionally, IT functions had been focused around a product development model with operations being dragged in tow as a little more than after market support.  The only difference was that IT had a captive market or so the unconscious bias appears to be within these organizations.  As the IT industry has aged, other goal expectations were placed upon these organizations.  These ranged from being the gatekeeper to precious information, the controller for allocating technology & resources, and the integrating force between other parts of the organization. Whether it is possible for one function to successfully execute on all three missions is a topic for another post.

These expectations struck a nerve with me as I was reading Step Guide for Building a Great Company .  I have been researching business strategy, models and processes for most of my career.  As I read through the first few pages I wondered if IT Functions were not using the wrong business model.  In the past decade many IT functions are desperately trying to change their culture to a service oriented business.  Initiatives such as ITIL, COBIT, and SOA seek to inject a service mindset.  I think the objective is a laudable.  Having experienced a slightly less than customer / service oriented environment decades ago (a story for another time over a beer).

However, the typical service model that is put in place is one for a stabilized or mature business.  A business that has a standardized set of services that are being optimized, not a service that is constantly evolving which has been the nature of the IT function over the past several decades: Mainframes, PC/Workstations, Network, Internet, and now Cloud and BYOD.  This would not be considered a stable and mature industry as the technology keeps changing.  The  consider as the technology keeps changing new services are being either asked for or developed constantly.

With that fact I wonder if the business model IT functions should use is that of a Startup or possibly a bifurcated model that has service groups start out in incubators and move into optimization models as the service matures.  This is very similar to the extension’s I developed for another employer with regard to managing business portfolios.  I had based much of the initial work on The Alchemy of Growth: Practical Insights for Building the Enduring Enterprise adding another horizon and much more recently figuring out how to tie each horizon portfolio together using Real Options and Cluster Analysis.

In this recent expansion new services in ideation are considered a new business opportunity or new technology opportunity.  This determines if they are a Horizon 3 or Horizon 4 portfolio member.  As the internal market/business develops or the technology becomes understandable and stable enough to pilot these opportunities move onto the next portfolio where different operating rules and metrics are applied to manage these.

The result of using such a model makes the IT Function vertically integrated business incubator going from Founder & Angel Investor, to Startup & Venture Capitalist, to an stabilized operating line of business.   Which leads to yet another simulation model to build for my clients and possible discussion at next April’s Engineering Conference.

Structure in Threes: Service Design\Service Quality Part 2

This morning’s R&D started white boarding merging ServQual with Cluster Analysis & Stakeholder Analysis/Management methods to develop a measurement system for Service Value Management.  Reached out yesterday to an old IBM colleague — Bradford Hobbs, now running BizBrand Foundry– in connect to some R&D we did together on measuring brand value in a more objective verse subjective manner.   Like Brand Value can influence sales price on products (e.g., Firebird vs. Camaro which were essentially the same vehicle) Brand Value and what influences it will influence sales price of services (e.g., Brand X Business Management Consulting Service vs. McKinsey both may perform the same activity and to the same quality but the later receives a premium from its Brand Image.  I can foresee the same factors and phenomenon equally working in the IT Services arena:  IBM Cloud, Microsoft Cloud, Amazon Cloud, Apple Cloud, Google Cloud, etc.

What will separate the prices paid and the margins enjoyed by these corporations for providing these services will be more than just the actual technical performance.  The Brand image of the company, experience the user enjoys and expects which will either enhance or detract from the Brand image and perceived value which will ultimately influence the price a customer will be willing to pay.  While there are subjective studies on measuring Brand Value of products, I’m literature search so far on Service Brand Value has yielded very little other than subjective measures of service quality.  As such it looks to be a interesting area of Brad and I to collaborate upon once again.