Enterprise Architecture Catalog++

Every dream about having a catalog of the complete design of your enterprise?  One that not only gives you and inventory and status of components, but also gives you the relationships between those to create higher level objects: Business and Operational Models, Capabilities, Processes.  How about linking in how these play against your business and technical strategies or assessing those strategies against your abilities to achieve?   Well the wait is almost over, because I’m almost finished building it!

Several decades ago when I met John Zachman for the first time I was impressed by his curiosity about what I was doing at Rockwell.  I was using a CAD/CAM system to design a factory.  Not only the floor plan, but the systems, applications, information flow, etc.  Several years later after John had released his brilliance regarding Enterprise Architecture I got to meet up with his again.  From our talk and his insight I’ve been working on creating a CAD for Enterprise(TM) system.  One that would enable Enterprise Architects to work with Executive Teams to design the enterprise of their dreams like designing a house.  While the UX/UI will take a while longer, the Minimal Viable Product (MVP) database which is what the application will rest upon is almost complete with a usable text-based UI.   I will be considering just a few Testers for this MVP in the next few months as well as possible partnerships with graphical design tool vendors**.  Details to follow on how-to sign up.

**Graphical Design Tool Vendors you can contact me directly now.

Advertisements

Are you designing your Enterprise or just copying someone else’s wiring plan?

Last week a former executive client of mine and I discussed his latest initiative: “Digital Transformation”. He was all excited about moving to the cloud, AI, and a host of other hype cycle buzzwords. After attending an analyst firm’s briefing about the latest and greatest technology trends. With his CIO in tow he was ready to invest in moving applications from his on-premise infrastructure to the cloud and magically have his business transformed.

Now my former client is also a friend so I can speak candidly to him. I asked one simple questions of him. “Aside from changing the technology you’re using, what are you going to do differently that would make you say you’ve transformed your business?”   “Well were scalable now and….” “Oh, so adding another server in your on-premise infrastructure is not scalable also?”. I could see he was getting very uncomfortable about my questions.

Next came the flash of insight I hoped would occur. “Are you trying to tell be all this doesn’t matter?” My response “Does it?” After a few awkward moments “It does but I’m not sure why”. “Tell me. You have a really nice house. Would you be willing to rip out all the wiring, replace the receptacles and switches because some new wiring technology has come to market?” A puzzled look for a moment, then a “That’s crazy, I’d only do that if it enabled me to do a lot more or something different with my house…” Then a pause and a second flash of insight. “I get it! You’re not say don’t go to the cloud. You’re saying ask what I’m going to do differently that the cloud will enable me to do”. Then a friendly dig back at me. “Just like a consultant always giving a depends answer and telling me what I already know”. “Maybe so, but would you have asked yourself those questions before coming to me. Clearly there was a reason you called me up after a couple of years have passed since our last set of discussions”.   “Brian, you’re sounding more and more each time we talk like a psychoanalyst”

“So, Doctor Brian, what should I do?”. “First off, lay here on the couch…. Seriously, the question you should be asking yourself is; am I repeating someone else’s wiring plan in my house (a pattern) and do I expect to get a competitive advantage from doing what others are already doing?”

I’m a great believer in patterns. Patterns in whatever shape and form they are: frameworks, templates, etc. help you organize information so you can focus on the innovation potential locked away in it. Implementing patterns also mean you have to focus less on routine activities that are necessary but don’t provide differentiation and advantage.   Also, examining patterns can give you insight into opportunities or threats and weaknesses. That is by examining patterns you can learn on another person’s dime.

With this little vignette and hopefully passing some insight to you, I’ll ask: Are you designing your Enterprise or just copying someone else’s wiring plan?

Enterprise Portfolio Management Series: Innovation within and existing Enterprise

Enjoyed Alexander Osterwalder’ s article on Portfolio Management today. He covers some of the same ground I’ve been presenting within Microsoft, DMR and IBM over the years. The enterprise has many portfolios. These are categorized in hierarchies, functional domains, temporal horizons, as well as the innovate/exploit Portfolios.

The issue I found within many organizations was with the cross-over from Innovate to Exploit. While at IBM it took a while to build out the practices to somewhat effectively do such. At IBM we had embraced “Alchemy of Growth” for portfolios but the transition became the stumbling block. At other companies I’ve consulted to, it’s the same. Creating that system that enables escape velocity from the innovation center and then captured into a new orbit around the performance center of gravity ( i.e., exploitation of the innovation into the core business ) is no small challenge.

This issue will be addressed in the Enterprise Portfolio Management Levels 3/4/5 articles in the series.

Slide Notes

Today one hears a lot about innovation or being innovative in an enterprise. However, and enterprise by its nature seeks to maintain a status quo. For an Enterprise to survive today management needs to create an equilibrium between innovation and performance.

The two major centers of gravity in an enterprise are its innovation and performance engines – “Beyond the Idea”

Concepts, Initiatives, and Activities will stay in the gravitational sphere that supports these unless escape velocity is reached

Once escape velocity is reached unless influenced by another gravitational center these items will spin off into the void

Effective portfolio actions assist in the change in mass in each of the gravity centers of an enterprise.

Beyond the Idea: How to Execute Innovation in Any Organization, Vijay Govindarajan & Chris Trimble, 2013

Is your APM strategy a yard sale or a Beauty Pageant?

This and the next few weeks Carl Engel (Elyon Strategies CEO) and I are collaborating on a white paper about Enterprise Portfolio Management. The insight that we should do this came about a month or so ago at a Industry Vendor’s Conference where we saw some serious misalignment in presentations touting Agile and APM as the key to success. Our objective behind such is to give executives insight and tips how-to implement a beneficial portfolio practice beyond just APM.    My strategy creating this paper is to provide the “Cliff’s Notes**” on the Enterprise Portfolio Management practice I’ve been maturing over the decades for various consulting, technology firms and their clients.

During our brainstorming sessions one insight has continually come to the forefront.  The state of the art in APM is drastically behind the state of the industry in financial portfolio management.  Not only that but the practice in APM could actually be damaging to an enterprise.  Here is one insight from our brainstorming session:

Application Portfolio Management (APM)

APM as practiced by many IT organizations and consulting firms typically focuses on one of two strategies: Rationalization of Current or Curation of Potential.  In the first strategy the organization is seeking to ride itself of assets in its portfolio.  In the second strategy picking individual winners or highest winners is the goal.  Both of these objectives are well meaning however, if not accomplished in alignment to an enterprise’s business can prove devastating.

Portfolio Management was originally introduced as a strategy to balance risk and reward in the financial investment industry by Nobel Prize-winning economist Harry Markowitz.  As the concept of portfolio management migrated to IT the second factor, risk, seemed to have been dropped from consideration.  If a root cause analysis had been accomplished you’d likely find many of the serious issues within IT can be traced back to not considering the enterprise risk of the equation.

With regard to the first strategy Rationalization.  Lets consider why one is “rationalizing” the portfolio.  In several engagements I was brought in, was due to acquisition of multiple assets or copies of assets doing the same thing.  The root questions is why?  The other situation was the asset did not perform or no longer performs at the desired level.  The end result of such is these assets are like the tail end of a yard sale. The only thing left to do with them is box them up for charity (unlikely) or putting that ugly lamp into the trash to be hauled away and forget about them.  But why did this occur?  If it was an asset to the enterprise shouldn’t it have been managed as such?

In regards to the second strategy Curation of Potential, there are many books, consultants and firms touting how-to develop effective business cases for initiatives.   I’ve co-developed several of these for corporations such as IBM, Microsoft, and other consulting firms.  Unfortunately despite cautions to the contrary, these are often watered down to eliminate the interdependence risk portion of the equation.  This creates a popularity contest for funds.  This maybe due to self-interest by the initiative promoter, a lack of insight as to the interdependence of the initiative within the enterprise ecosystem or that no one wishes to discuss the potential downside: “You’re just being negative…”  In any of those cases the risk to an enterprise is an iceberg in the ocean the enterprise is sailing through.

The forthcoming white paper will provide some tips on effective Enterprise Portfolio Management, while the training course to follow will delve deeper into how-to establish and mature a portfolio management practice.  This will also help enterprise determine at what level they are and what level of practice is optimum for them.  That is not every enterprise needs to or should be at a Level 5  of capability/maturity.

 

 

 

**Shorter versions of Dummies books for those born later than Boomers

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.             

            

Why should I believe a consulting firm that doesn’t have a service catalog or any other company?

Let’s see you’re a technology consulting firm or any consulting firm and you don’t have a service catalog.   When you’re advising my company, you bring to the table a wealth of technology-speak: Cloud, Digital Transformation, AI, Containers, Blockchain, IoT, and the like.

Asked what your firm does I hear a jumble of more buzz-words: Agile, Digital Design, and the list goes on. Pressed for a simple answer I get “We’ll assist or execute for you in implementing the latest technologies”. So basically, your service catalog contains two items: Project Management and Technology of the Moment (TotM) implementation.   “Well we do more than that. We also provide Agile Training, Coaching, and blah, blah, blah…” Isn’t all of that in support of the two services you are supplying?

I know a few years ago your firm was trying to engage with my firm’s IT function about improving operational efficiency. You were proposing that you could help us by creating a service catalog as part of implementing a service management strategy.   We’re still working on creating our catalog. Can we see yours?

Oh, you have a list of services you advertise but no real catalog of how to perform or measure? Then a quick scramble behind the scenes to dig up you Secret Sause Methodology that no one else has. But I’ve seen this by every other firm just with different company specific acronyms.

I begin to wonder why if your firm had highlighted how important having a service catalog was so important years ago, that you don’t have one also. Especially since you still insist its key to an effective organization expecting to digitally transform itself.

While this is a rude hypothetical example. I assure you the events and thoughts are real, confirmed through discussions with many Executives over the years.

I don’t claim a service catalog is the answer to all of life’s questions, nor will it make a poorly conceived business model suddenly become profitable. What I do suggest is that a well thought out service catalog is part of good business and operating models.

.

These models “guide” a company to success. Provided one understands these are models not the real world. These are the visualization of planning. Eris Ries along with other notable business advisors suggests two important concepts about enterprises and growth. First, you can expect you’ll need to change your business model or plans once you engage with the market. The ecosystem will inform you what is of value to your clients and your business. Second, if you focus on doing everything, you’ll eventually do nothing. For all the resources mega-enterprises have, these still must focus. It’s when they lose focus and try to do too much outside the core the business goes off the rails.

So where does a service catalog come into play?

Service catalogs are the details behind what your firm does and does not do, and how it does these. This may be why there are so many small consulting firms with big dreams that never grow up. Either not knowing what they do, trying to do everything, or not understanding how to do it repeatedly (a service) with consistent and measurable results.

Imagine going to a Cleaners only to get your clothes back partly cleaned one time, fully cleaned another, and having the service period vary by days without any indication as to when. Then going into the back room to see people cleaning clothes in no consistent manner: a dry-cleaning machine all the way through using a tub and scrubbing board. How long would you consider using this “service”?

While there is no guarantee that having a service catalog will ensure the perfect outcome. Having a one along with management oversight increases the probability of that desired outcome. Coupled with service agreements this reduces the risk to the client.

So why have a service catalog?

A service catalog is the guide rails to good outcomes for both client and company. The services included in the catalog are the execution details behind the key activities of your business.

Methodology Engine for Consultants

Early wake-up call…well not actually early for me.  Today’s agenda: More Data Mining and evaluating the best course to capture methodology for my consulting firm.   Four primary factors to consider: 1) Knowledge and Skills transfer 2) Job Aid and Execution support 3) Ease of maintenance 4) Accessibility for field consultants

In prior roles I help construct or constructed my own methodology engines for various domains: Marketing Management and Strategic Planning, Enterprise Assessments (e.g., ISO 9000, CALS, etc.).  Depending upon factor four the technology choices I had narrowed down to were: Lotus Notes, SharePoint, and MS Access.  Of all the platforms to build on, MS Access was the most popular as one could carry the engine into a client’s site where Internet access was limited.

 

I was consider a hybrid on desktop MS Access and Access Services, however, given the uncertain future of both I’m considering another option such as Pega which would have the accessibility limitation pointed our prior, but gains an orchestration engine and data consolidation of multiple engagements for future BI application.  However, to kick start the project I’ll likely use the Methodology Engine I created in ACCESS as it has the basics to capture the workflow, methods and R&Rs