The Death of Enterprise Architecture

ea-tombstoneThis morning I read a rather despondent post by a peer seemingly on the verge of giving up Enterprise Architecture.  Not a particularly happy thought.  It was reminiscent of the death knells I heard a few decades ago and seems to repeat each decade.  

At that time large corporations had just come off of a great high on Strategic Planning, Enterprise Architecture, and other master planning activities.  There was a great trough of disillusion regarding any planning activities.  Comments like “things are always changing, so planning is a waste”; “you can’t plan for everything”; and other criticisms of planning and design were popular in the culture. 

Such comments resonate well in the cowboy culture of American Business; except when it comes to production where tremendous efforts to plan resource utilization are common.  Look at the success of ERP software as an example. 

My thoughts on ERP mega-success verses other Design and Planning software moderate success draws me to the conclusions I had back during the first trough of disillusion.  At that time “Architecture Practice”, that is the design of physical dwellings, had hit a slump or rather a restructuring.  I had been informed a career in designing buildings was going to be a difficult undertaking as investment in construction had dropped and one of the cost cutting measures development organizations and people were taking was to reuse designs (patterns and practices) rather than create or customize to individual preferences.  The perceived cost verses the benefits of hiring an architect were not in balance.  As such the question I had for my advisors: Will I be on a street corner with a sign “Will design a house for food” seemed poignant. 

Fast forward to today.  Many of my peers back then left the profession within two to four years seeing that the industry restructuring had reduced the capacity of resources needed to meet demand.  

There are strong parallels to today.  With the advent of best practices, templates, etc. the needed capacity for parametric designers (i.e., template completion staff) has reduced.  As such the role in EA has more and more become closely associated with IT presales and support.  This maybe because of its origins in information technology presales and support.  

Whether this is good or bad is up for discussion.  On the positive side such roles enable one to learn and develop soft skills working with line of business and possibly executive management.  On the negative side it often constrains one to focusing on the technology aspects of an enterprise.  Those thoughts of working to define the business are often far from reach.  Your role is to translate business capabilities defined by the business design into technology requirements, determine which technology is most appropriate, or defined implementation details. 

Notice I did not mention defining the business or business model.  Until you are in the inner circle of Executive or Line of Business Management you are unlikely to be given the opportunity to define or influence the business design.  If lucky, you’ll be asked to document the business model.  This would be the entre into business design.  From there if you can provide insight and value regarding the business model choices from other than a technology perspective you may be invited into the inner circle as an “intern”. 

The thing to remember here is that, its their business, not yours.  You’ve been invited to give insight, not criticize or make decisions.  Unlike Frank Lloyd Wright you don’t have a successful brand as a business designer, that enables you to dictate all the aspects of a design your client will have to accept if s/he wants a “Frank Lloyd Wright” House.   The closest to such defined business models that owners accept as given would be franchises like Mc Donald’s, etc.  There the business model has reached into the best practices, Patterns and Practices level.  

So what does that say about Enterprise Architecture and where it should report to?  Yes, designing the business is possible, but it will take time and effort to gain trust to be given those opportunities.  Understanding your role as a translator of business capabilities to technology will likely be the core of your practice.  While business model design and definition will be needed stills, the freedom to change these are not often granted.             

 

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.

New Instructional Video Channel coming

Working on first instructional video for Digital Advisors and Enterprise & Business Architects for my new YouTube channel you can subscribe here: https://lnkd.in/gdxzmyW

KPIs – Key Performance Inhibitors and a method to transform theses back to Indicators

This month I am dividing my time between several initiatives at work:

  • Technology development activities
  • Process adoption
  • Metrics definition
  • Skills transfer

A rather interesting and eclectic combination of activities. But as I started to ponder these I started to reflect on the metrics definition activities of past and the relationship to other initiatives on my list. My goal is to create a suite of KPIs for my group that is useful in advancing our success. With that premise several things come to mind.

  • KPIs or metrics that truly indicate how the organization is progressing to its goals; rather than those fool us into believing we’re doing well when we’re not
  • KPUs that the organization believes in; that is, we have control in positively effecting these and can relate to achievement of our goals
  • KPIs that are diagnostic; they provide insights to help us determine what we can do better

This is a tall order considering people often are suspicious of how measurements are used. Especially if such has been used in the past not as guidance but justification for other agendas. This typically results in KPIs that are meaningless but always show green, even in the face of disaster. Such have a witnessed before within sales organizations that measured success by size of backlog rather than quality of backlog or customer satisfaction. This eventually became a game of musical chairs with the unlucky sales rep. at the end of the cycle taking the hit for a bad backlog he had nothing to do with.

Based upon such experience, my belief is that KPIs need to be a serious discussion and negotiation between all levels within the organization. Staff must believe that these measurements are able to be influenced by their actions; Management must believe these measurements indicate status of the journey to goal achievement.

These seem simple enough, except that the altitude that each party operates at is different. If you’re a Senior Executive you’re often looking at corporate performance: profit/loss, customer satisfaction, market share, etc. If you’re a programmer in IT you’re focus is on cost and time of delivering an application, response time of system, uptime, etc. This difference in metrics can and often does create misalignment between management and staff.

The results of which is often KPIs become Key Performance Inhibitors as staff become disillusioned with measurements as they can’t relate their measurements with goals management focuses on rather than how their measures relate to business measurements.

This conundrum can be address with a method called Hoshin Planning. Hoshin Planning is nothing more than a cascading set of matrices of goals, strategies, and measurements that relate one altitude of measurements to another. While the technique works well, it does require additional effort between management and staff to be explicit about the goals, tactics and measurements as well as reasonable in setting measures and targets that assignees believe are achievable. This however, is not a simple twenty-minute exercise and like all planning requires constraint revision in the light of new information (i.e., planning forecasts are not accounting transactions).

Why your planning sucks… and what to do about it

“In preparing for battle I have always found that plans are useless, but planning is indispensable.”Dwight D. Eisenhower

Over the years, I have the fortune or misfortune to be involved or observe various disastrous planning activities. Most of the time one could tell things were not likely to end well. Why then did these continue to an eventual bad end? Simply because people confused planning with plans.

Plans are the documentation of the activity at a specific point in time, not the end state. Too often plans are viewed as cast in cement, never to be changed, even in the light of an approaching cliff. The question then becomes why? From observations, I’ve conclude that much of it revolves around ego. If I’m the manager I’m supposed to have all the facts and answers. And my decisions cannot be changed as these are personal commitments and a change would reflect poorly on me.

What is needed in management now is like what happened in various design professions “Egoless… programming, etc.

A simple categorization of why changes to plans are needed often reflect aspects that are often not in control of management at the time a one and done plan is made and being executed.

  • Results from activities is not as expected
  • Conditions have changed since the plan was developed
  • Another factor has surfaced or has more impact than anticipated
  • New options have surfaced

All of these infer the need to adapt or adjust one’s plans. So why in business do we continue down the wrong path in the light of these. We’re back to plans vs. planning; cement verse wayfinding. If one adapts the notion of real options in planning, this might address the situation where planning becomes day to day activity rather than a concrete list of tasks to check off. Which may have us focus on desired outcomes rather than actions that we hope provide results.

Business Ecosystem Future –a look ahead

Had an interesting discussion yesterday morning with a colleague. Our discussions already are wide-range and free-wheeling.   This morning was no different. We discussed the nature and evolution of businesses. During that discussion, I brought up how information technology has changed from monolithic applications to small apps and my hypothesis as to why. Part of that rational I believe is due to two factors: First, the IT backlog and its increasing failure to address business needs. While many IT organizations have, or are switching over to “Agile” or “Addle” as several colleagues have called it due to many misfires, I look at Agile as one of many data points proving a change to the Business Ecosystem.

The days of monolithic anything is drawing to a close. Lean the precursor to Agile in manufacturing has been working its way upstream. What this suggests is that small and fast will been the dominate development and construction tactic of this age.

This then means that consulting firms will need to retool also not only learning fast production methods like agile but understanding how to address the complexities of many more loosely coupled components. Apps vs. Applications means that integration often happens between the ears rather than through the database or API.

The critical skills that Enterprise Architects and Consultants will need to develop are in opposition to their training:

·        Synthesis in addition to Analysis

·        Experimentation and tolerance for failure (often called learning)

·        Business Value Management

·        Complexity Management

·        Understanding of Options Theory planning

·        Business Lifecycle Management

This will mean a new type of consulting firm model as the nest in the shallows of a corporation as high priced contingency labor will be unacceptable to leadership, they’ll be looking for just-in-time consulting.

Strategy and Vision Analysis

Digging through some old files this afternoon to find this sketch from ’95.

vision-analysis-workflow

After I had decomposed a Senior Executive’s Strategy and Vision to find some of the major weaknesses and suggest mitigations, he asked me into his office.  He had only put out the document a few hours before.  Mind you I had just joined the company a few weeks before when I sent the critique; other’s had warned me that was a career limiting move.  That this Executive didn’t like criticism.  So when he called me into his office shortly after sending my assessment.  Well you can imagine I figured; it was going to be one of the shortest careers in the company.

To my surprise and delight, he gushed over my assessment.  Saying it was a brilliant piece of analysis and wished others in his organization could do such.  All he could ever get from his subordinates was a weak “Because we’ve always done it that way” or other “I just don’t like it without any rational explanation.  His next request during the meeting was simple,  he asked me how I could do such so quickly.  I pulled out some paper, sketching out my process as I describe how I performed each step, and how each step fed the next in line.

Today I’m still analyzing strategy and enterprise architecture, design and construction; though my tools have matured some what, the objective of each step are still the same.

 

I guess the saying the more things change the more they stay the same still rings true.  Though many don’t realize, most of the new solutions touted are really the same ones from the past, just masked in newer technology