I recently received a note 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 here in the U.S. The note outlined all of the objections to doing architecture that my friend was encountering.

The note is not significant because of one particular enterprise, nor of one particular industry. The note is significant because these are the kind of objections I hear day after day from many enterprises in many industries and the objections are coming from IT, not the Enterprise! I have copied the objections almost verbatim below.

Here is his intro:

"Dear John - By the way - I am getting some pretty significant pushback from the IT leaders. They do not want to do architecture (i.e. create models) for the business!"

Response 1: First, regarding "principles" -- I think "principles" are a great idea, but when people say "architecture principles" these days, they tend to have in mind simply principles related to hardware and systems software and overlook principles that relate to the systems (logical) architecture or to the business, itself. I would suggest that the hardware and systems software are merely the "container." The business (and therefore the applications systems that derive from the business) are the "CONTENTS."

It is the CONTENTS that the enterprise 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, the ENTERPRISE? If you define the container first, you are bound to constrain the contents, that is, you are bound to constrain the ENTERPRISE.

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 DIVERSITY." Having one of every kind of mainframe, server, workstation, operating system, DASD, database management system, network, network operating system, programming language, middleware, etc., etc. known to mankind is a luxury beyond most enterprises' ability to fund, not to mention change!

Interfacing hardware and systems software (with "middleware," for example) -- or "interfacing" anything, for that matter -- quickly gets out of control because the number of connections (interfaces) between "n" points is "n squared minus n over 2." As the number of points 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 hard bound together with customized, unique "interfaces!" That's one of the principal problems we have with the "legacy" today!

Next, assuming that "Reducing Diversity" is a good Technology Architecture (Col. 3, Row 4 ^[2]) principle, along with whatever other good Information Technology principles you want to define, the question then becomes: without some business involvement in producing some business models (i.e. Rows 1 and 2 models), coupled with the other Enterprise Architecture models (i.e. Row 3 and the other Row 4 models), how are you going to 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?

Assuming 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 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 Ö and somebody 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 nice Ö but there is no substitute for architecture (actual models) when things get complicated and start to change.

One 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 I/S? Or, does I/S exist to support the business?

I would argue that until we know what the business is and what its values and intentions are, (that is, until we have some Rows 1 and 2 Business Models), we can only make assumptions about the technology requirements -- and then the question is going to be, how good are our assumptions? How good have our technology assumptions been over the last 50 years? Is everybody happy? Is the business happy? Are we happy? Is anybody happy?

Last Ö You NEED models Ö and the business truly WILL BE HAPPY to pay for them, especially when they find out models are 20 to 30 times CHEAPER AND FASTER than you can deliver implementations without models, like you are trying to do today (see Response 5 to Objection 5, below).

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 to be the ones that identify the problem and advance OUR solution rather than risking somebody else deciding that WE are the problem and advancing 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 Ö how else do you intend to get our implementations aligned with what the enterprise needs, short of defining what the enterprise needs (that is, short of building the Rows 1 and 2 models) and then deriving our implementations (Rows 3, 4, and 5 models) directly from their own specification of the enterprise needs (Rows 1 and 2 models)? We are a lot better off surfacing the issue by actually solving the problem architecturally than getting our tail feathers out-sourced out of frustration.

Another observation Ö if the users are registering a little frustration with us and they are getting testy about building models or they are demanding some action, then I would argue that redoubling our efforts to write more code is not going to fix the problem. One definition of insanity I have heard is "continuing to do the same thing and expecting different results." We have been knocking our brains out writing code for 50 years Ö and if, after all this time and all this code, the users are still unhappy, I would suggest something has to change.

People ask me all the time, "Well, WHO has successfully implemented Architecture?!!" MY reaction to that one 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?!!"

In every enterprise I have seen where the users have become involved in building the Rows 1 and 2 models, their reaction tends to be, "Well, that makes sense!" Or, "Well Ö this is the first time I really understood how this business works!"

On the other hand, they 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, 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.

Response 3: You are absolutely RIGHT!! I have made the assertion time and time again 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 a whole article, "Packages Don't Let You Off the Hook" for a previous issue of the Newsletter and I won't attempt to reiterate all the points I made in that article here.)

I will raise one question, "how are you going to decide which package you are going to buy, that upon installation will BECOME YOUR ENTERPRISE?" Guess? If you don't have any models, guessing is the only option. And, the last time I implemented some packages, I seem to remember, "the devil is in the details!" Guessing is HIGH RISK!!

Here's another question, when you buy the package, are you buying an ARCHITECTED package? Ö or, are you buying a bunch more spaghetti code? If you are buying a bunch of spaghetti code, you don't have to buy that from somebody else, you already have a bunch of that in the legacy!

On the other hand, if you are buying an ARCHITECTED package, have you actually SEEN the architecture (that is, the models)? And, oh, by the way, how do those models compare with your enterprises' models? (Of course, that is the way to select the package Ö based on the fit between the package architecture and your Enterprise Architecture.) And, oh, one more question, how will the new package architecture "integrate" with all the other applications that presently constitute your "legacy?" 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!! (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 Enterprise, starts getting frustrated!

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 the matter with your current architecture? If you are going to build your new architecture in 3 months Ö and not build any models Ö what is your logic for why you are going to be happier with (or why your new architecture is going to be any better than) your current architecture?

Oh, you say, your current architecture is not really architecture because it just happened Ö you never Ö you never "engineered" it, that is, you never actually built any Ö models Ö Hmmmmm, tell me again -- if you don't have time to build any models, why will your new architecture without models be any more "architecture" than your current lack of architecture without models?

If you want Architecture then, by definition, you are going to have to architect (build models)!

Response 5: Clearly, we are running out of time -- but banking 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, and you are buying someone else's design for your business (see response 3 to the application package objection above). The question in this case is going to be: how do you select the functions 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 architecture (models) and your enterprise also has architecture (models).

Second, if it was easy to make pre-manufactured functions work together, you wouldn't have to buy the functions to begin with! You could just make the pre-manufactured functions you already have installed (your legacy) work together. That is, if it was so easy to post-integrate things, you wouldn't have a legacy problem to begin with. The assumption that you can buy application functions and "just" make them work together is simply not a reasonable 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 engineering design objective for the 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. Early numbers are indicating that, even with limited industry experience, twenty to thirty TIMES reduction in TIME and COST are easily achievable using top-down, model-driven, architecture-based approaches.

Once again, buying functions 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 well be a lot cheaper and faster and require fewer competent technical types and programmers than trying to buy functions and fit them together, after the fact.

Finally, here is the best objection of all!! FROM THE CIO him (or her) self no less:

Response 6: People just don't seem to get this!! The REAL value that IT provides to the Enterprise is the models of the Enterprise, that is, Enterprise Architecture. Why? Because Enterprise Architecture constitutes the total KNOWLEDGE BASE for the Enterprise -- everything anyone wants to know about the Enterprise or how to change the Enterprise. In the Information Age (or, maybe it should be called the "Knowledge Age") it is the Enterprise that has first knowledge and can change the fastest that wins the game.

Modeling is NOT planning!!!!!!! MODELING IS ACTUAL WORK, vital work -- that is, VITAL, 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 (which is now officially OVER).

If you think that work is only comprised of code (that is, implementations), you are going to count lines of code produced as a measure of progress. Then, you are going to get more lines of code. Whatever you measure, that is what you are going to get! Your 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. You will be so far out on the short term end of the spectrum you may never be able to recover, and when you get the "pay me now or pay me later" bill, you are not likely to be able to pay it!

We (IT) have been taking the short-term option for the last 50 years. That is what the problem with the legacy is today, as well as the reason why we are unable to respond to short-term demand with quick implementations Ö NO ARCHITECTURE, we only do code!

In summary,

I remind you that the 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, the high probability is we will only continue to aggravate the problem. Redoubling our efforts to write code with better tools and technology 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 in order to survive the business challenges of the new millennium.

Notes:

1. Walt Kelly Pogo cartoon of many years ago.

2. The references to Rows and Columns or Cells (models) in this article refer to the Framework for Enterprise Architecture which has been amply described in previous Newsletter articles.