Affiliated with:

A Continuing Struggle with Enterprise Architecture

Picture1

Proper enterprise architecture must include business focus and business involvement, and models of business requirements at all levels are needed as well as models for hardware, software, network, data, etc.…

Introduction

Recently, I received a letter from a friend of mine who was valiantly trying to initiate some architectural activity in a very large enterprise within a very important industry sector. The note outlined all the objections to doing architecture that my friend was encountering. The note is not significant because of one particular enterprise, or of one particular industry. The note is significant, because these are objections I hear continually, from many enterprises in many industries, and the objections are coming from IT, not the business! I have copied the objections almost verbatim below.

Objections to Enterprise Architecture and Responses

Here is his intro: “Dear John – By the way – I am getting some pretty significant pushback from the Information Technology (IT) leaders. They do not want to do architecture (i.e. create models) for the business!”

Objection 1: “Let’s just use architecture principles instead of building any models. We can figure out what we need in IT (without any business involvement) and the business is going to pay for it anyway. We don’t need any models.”

Response 1: First, regarding “principles” –

I think “principles” are a great idea, but when people say “architecture principles” these days, they tend to mean simply principles related to hardware and systems software and overlook principles that relate to the systems (logic) architecture or to the business (concept) architecture. I would suggest that the hardware and systems software are merely the “container.” The business (and therefore, the “systems” that derive from the business) are the “contents.” It is the contents that the organization really cares about. How do you figure out what the “container” has to look like until you understand what you are going to put into it, that is, the contents?” If you define the container first, you are bound to constrain the contents to the container.

I grant you, there is one hardware and systems software principle that I can think of that doesn’t require any understanding of the business and that is, “reduce redundancy / diversity.” Having one of every kind of mainframe, server, workstation, operating system, DASD, database management system, network, network operating system, programming language, middleware, etc. known to mankind is a luxury beyond most organizations’ ability to fund, not to mention change! Interfacing hardware and systems software quickly gets out of control. As the number of points to interface increases, the number of interfaces increases exponentially! If that isn’t enough, if you add enough interfaces, the technology ultimately will atrophy. It will become impossible to change anything because all the points are connected with customized, unique “interfaces!” Interface management and change is one of the principal problems we have with legacy systems that remain entrenched in organizations of every size in every industry.

Next, assume that “reducing diversity” is a good Technology Architecture principle (Col. 3, Row 4 from the Zachman framework); along with whatever other good Information Technology principles you want to define. Without business involvement in producing some business models (i.e. Rows 1 and 2 “primitive / elemental” models), coupled with the other Enterprise Architecture models (i.e. Row 3 and the other Row 4 models), how will you decide what specific hardware and specific systems software to put in what specific location? How do you draw any supportable, logical conclusions about the technology without any architectural models?

Assume for a moment you can somehow figure out (without any business models) what technology to put in what location, after you get a few thousand nodes in the network, and you have no record (that is, no models, no defined architecture) of what hardware is in what location, with what configuration, running what systems software with what configuration and what version, performing what application functions in what languages using what data in what format in what database management system, and so on, and so on …. Now, someone wants to change something … by anytime tomorrow morning?!! Now what do you do? Go out and start taking a physical inventory of all the technology (containers and contents) from scratch?!! Good luck!

I would argue, principles are useful … but there is no substitute for architecture (actual, documented “primitive / elemental” models) when things get complicated and start to change.

One last comment regarding “the business is going to pay for it anyway!” What is the logic here? Has someone lost sight of who is the customer and who is the supplier? Does the business exist to support the Information Technology department? Or, does IT exist to support the business? I would argue that until we know what the business is and what its values and intentions are, we can only make assumptions about the technology requirements, and then the questions are how good are our assumptions and how good have our assumptions been over the last 50 years? It seems as if we need some Rows 1 and 2 business models before we embark on defining the specific technology requirements.

Organizations need models … and the business truly will be happy to pay for them, especially when they find out that implementations built from models are 20 to 30 times cheaper and faster than implementations delivered without models, like organizations are trying to do today (see Response 5 to Objection 5, below).

Objection 2: “The business thinks we have been trying to serve their needs all along. We better not show up now and suggest we don’t know how the business works and therefore, state that need to build models. It will create one heck of a problem for us in IT! The users don’t want to build models anyway! They want action! We have to just pick an implementation project and work on that.”

Response 2: Good night! This is the ostrich approach. We’ll just bury our head in the sand and hope the problem goes away before somebody blows off our tail feathers! I would suggest that we would be far better off as the ones who identify the problem and advance our solution rather than take the chance that someone else will decide that we are the problem and advance their solution!

For example, if the enterprise does not feel that whatever we are implementing is aligned with their needs, and they are not getting value for the money spent on IT they will choose to spend their funds elsewhere. To prevent the business from going to another supplier, the IT leaders and staff must align implementations with what the enterprise needs by defining what the Enterprise needs. This is done through building the Rows 1 and 2 models, and then deriving our implementations (Rows 3, 4 and 5 models) directly from the business specification of the enterprise needs (Rows 1 and 2 models). The organization and IT thrive when issues are raised and problems are solved architecturally through building the progression of documented requirements with models starting with Rows 1 and 2. This is much preferable to getting our tail feathers out-sourced due to frustration.

Another observation … if the users are registering a little frustration with IT and they are getting testy about building models or they are demanding some action, redoubling efforts to write more code is not going to fix the problem. One definition of insanity is “continuing to do the same thing and expecting different results.” Writing code for 50 years does not seem to have made the solutions work properly for the organizations. If, after all this time and all this code, the users are still unhappy, I would suggest that something has to change.

People ask me all the time, “Well, who has successfully implemented Enterprise Architecture?” My reaction to that question is, “Well who has successfully implemented the ‘you start writing the code and I’ll go find out what the users have in mind’ approach?”

Every enterprise I have seen where the users have become involved in building the Rows 1 and 2 models has a similar reaction. “Well, that makes sense!” Or, “Well … this is the first time I really understood how this business works!” On the other hand, business people do get a little testy about models when we are trying to get them to define Rows 4 or 5 models. Their reaction in that case tends to be, “Look! I hired you to be the IT person! I am a BUSINESS person!” I would argue that the users are not interested in becoming programmers or database administrators but they have no problem building business models that serve their own business purposes.

Objection 3. “We are going to buy some packages over the next several months; therefore we don’t need to do architecture. The packages are our architecture.”

Response 3: You are absolutely right! I have made the assertion repeatedly that “the system is the enterprise” and if you are buying packages, you are buying someone else’s design (architecture) for your enterprise. I wrote another article, “Packages Don’t Let You Off the Hook” which can be found in an Appendix of my book, The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing, available through www.ZachmanInternational.com. I won’t attempt to reiterate all the points I made in that article here.

I will raise one question, “How will you decide which package you will buy, that upon installation will become your enterprise?” Will you guess? If you don’t have any models with documentation, guessing is the only option. Moreover, based on the last time I implemented some packages, I seem to remember, “The devil is in the details!” Guessing is high risk!

An important question to ask when you buy the package concerns the availability of models for the package. Are you buying an architected package (i.e. one for which there are “primitive / elemental” models)? Or, are you buying a collection of spaghetti code – an application without documented elemental models that the vendor will supply? If you are buying spaghetti code, you don’t have to buy that from somebody else, you already have that in the legacy application! On the other hand, if you are buying an architected package, have you actually seen the architecture (that is, the models and their associated documentation)? And, how do those models compare with your enterprise’s models? This is the way to select the package … based on the fit between the package architecture and your Enterprise Architecture. How will the new package architecture integrate with all the other applications that presently constitute your current system’s environment? Or, maybe you just don’t want to be bothered about integration as you are just trying to add some more applications (packages) and increase the size and unmanageability of the legacy environment! (Read irony here.)

I would suggest, these are the kind of questions that someone, hopefully somebody from IT, should ask before you actually get money invested in the package and somebody else, like the business, starts getting frustrated!

Objection 4: “We need the system (technology) architecture in 3 months. We don’t have time to build a bunch of models.”

Response 4: Oh … 3 months … hmmmmm … that’s a little short! Here’s an idea … why don’t you just use the architecture you have now? You could do that in ZERO months!

Oh, you say … you are not happy with, or there is something wrong with your current architecture, or it costs too much to maintain it, or you can’t change it. If you will build your new architecture in 3 months and not build any models, explain your reasons about how the new architecture will be any better than your current architecture. Oh, you say, your current architecture is not really architecture because it just happened. You never designed it, which means you never actually built any models. Tell me again, if you don’t have time to build any models, why will your new architecture without models be any more architecturally sound than your current lack of architecture without models?

If you want architecture, then by definition, you are going to have to build “primitive / elemental” models! Final point: basic models can be built in 3 months by experienced people supported by knowledgeable business users.

Objection 5: “When it comes to the application functions (services) that we need, we don’t have time to build them anymore, we have to buy them. They are too big and too complex to build with the few good programmers and technical people we have. All we have time to do is to make them (the purchased functions) work together.”

Response 5: Clearly, we are running out of time … but relying on buying functions, particularly big and complex functions, may not be the solution to the problem.

First, buying off-the-shelf, big and complex functions is the equivalent of buying off-the-shelf applications packages. With them, you are buying someone else’s design for your business (see response 3 to the application package objection above). The question is, in this case, how do you select the functions (services) that fit your business? The answer is, you compare the application’s architecture with your Enterprise Architecture, but that presumes that both the commercial off-the-shelf product has an architecture available to you (“primitive” documented models) and your enterprise also has an architecture (“primitive” documented models).

Second, if it were easy to make pre-manufactured functions work together, you wouldn’t have to buy the functions! You could just make the pre-manufactured functions you already have installed (i.e., your legacy environment) work together. That is, if it were so easy to post-integrate things, you wouldn’t have a legacy problem. The assumption that you can buy application functions and “just” make them work together is simply not a rational assumption to make.

The only reasonable strategy to reduce “time-to-market” for Information Technology implementations is to take Enterprise Architecture-based approaches in which reusability is the enterprise engineering design objective for the enterprise architectural components that comprise the Enterprise Architecture. You have to have the Enterprise “architected” with standard, interchangeable components long before you get an order for a new application implementation. Research has begun to show that even with limited industry experience, 20 to 30 times reduction in time and cost are easily achievable using top-down, model-driven, enterprise-architecture-based approaches.

Once again, buying functions (services) off the shelf is not a substitute for architecture. In fact, successful implementation of off-the-shelf functions is dependent upon architecture. Furthermore, building your own Enterprise Architecture may be a lot cheaper and faster and require fewer competent technical staff, than trying to buy functions and fit them together, after the fact.

Now, here is the best objection of all! From the CIO him (or her) self:

Objection 6: “I believe we need to be ‘done’ on explaining what we will do and start actually doing it. I think my “direct reports” understand this to a degree and don’t want to hear any more about planning.”

Response 6: People just don’t seem to understand the value of modeling, data management, and designing as part of the work process! A very real value that IT provides to the enterprise is the models of the enterprise. These models are the Enterprise Architecture, and Enterprise Architecture constitutes the total knowledge base for the enterprise. A knowledge base is everything anyone wants to know about the enterprise to manage it or to change it. In the Information Age (or, maybe it should be called the “Knowledge Age”) the enterprise that has first knowledge and can change the fastest wins the game. Modeling is NOT planning! Modeling is actual work, vital work, if you think knowledge and change are important to the enterprise.

Anybody who thinks that actual work is not being done until code is produced is missing the point. The code is merely an interesting by-product of the modeling. Automation is not the end game. Knowledge and change are the end game of the Information Age. Automation was the end game in the Industrial Age, an age that ended some time ago. If you think that work is only comprised of code and implementations, you are going to count lines of code produced as a measure of progress. This means that you are going to get more lines of code. Whatever you measure, that is what you will get!

A myopic strategy clearly is “you start writing the code and I’ll go find out what the users have in mind” to the nth degree, because that’s the best way to meet the measurements. Organizations that adopt this view will be so far out on the short term end of the spectrum they may never be able to recover, and when they get the “pay me now or pay me later” bill, they are not likely to be able to pay it!

IT organizations have been taking the short-term option for the last 50 years. The problem with the current environment as well as the reason why we are unable to respond to short term demand with quick implementations is no architecture … “we only do code!”

Conclusion

I remind you that these kinds of objections discussed above are coming from the Information Technology Management community. We are our own worst enemy. Until we start believing that Enterprise Architecture holds some promise for bringing our enterprises into the Information Age, it is highly probable that we will only continue to aggravate the problem. Redoubling our efforts to write code with better tools and technologies only recreates all the same problems we have today, only bigger and faster!

Enterprise Architecture doesn’t happen in a moment, but it does hold the potential for setting us on the new course our enterprises need to navigate to survive the business challenges of the 21st Century.

LinkedIn
Facebook
Twitter

John A. Zachman

John A. Zachman is the originator of the “Framework for Enterprise Architecture” which has received broad acceptance around the world as an integrative framework, or “periodic table” of descriptive representations for Enterprises. Mr. Zachman is not only known for this work on Enterprise Architecture, but is also known for his early contributions to IBM’s Information Strategy methodology (Business Systems Planning) as well as to their Executive team planning techniques (Intensive Planning). He also operates his own education and consulting business, Zachman International.

© Since 1997 to the present – Enterprise Warehousing Solutions, Inc. (EWSolutions). All Rights Reserved

Subscribe To DMU

Be the first to hear about articles, tips, and opportunities for improving your data management career.