ENTARCO’S Methodology for Enterprise Architecture!

Why?
The Methodology for Enterprise Architecture (MEA) is a commercially proven methodology that alleviates deficiencies that have existed in business systems since the inception of the computer age some 40+ years ago.

The list of problems that have plagued business systems is well known because they have been ever-present since the inception of the data processing industry.  This list of business systems problems, given there may be a few variations over time and with varying degrees of severity, is pretty much as follows.

The business systems:

1. Don’t conform to business requirements.  This problem has come to be known as the “alignment” problem.
2. Cost too much and the costs keep going up.
3. Take too long to develop and keeps taking longer.
4. Lack integration.  There is too much systems fragmentation, duplication and inconsistency across the enterprise and we can’t fix it or we can’t afford to fix it.
5. Contain data that too often is wrong, inconsistent, and not accessible when it is needed.
6. Are not flexible and when we want to change the business it takes too long and costs too much to change the systems.
7. Maintenance takes up too many resources and is becoming less and less affordable.
8. Are difficult and expensive to change to implement new technology.
9. Seem to make it difficult to acquire, develop, and retain qualified people.

Do you recognize these problems?  If you do, it is also important to recognize a few other things.

1. This is pretty much the same list that has existed for the last 40+ years!
2. Advances in technology have not solved these problems!
3. Outsourcing systems development or the whole IT function is not going to solve these problems! That will make them worse!
4. Buying packages is not going to solve these problems.  That will make them worse!

These problems exist, and continue to exist because the fundamental process and skills that the information systems profession has been using to develop business systems has not fundamentally changed since the industry was in its infancy….some 40+ years ago.  Yes, systems have been developed and deployed with incremental improvements in business operations, but with significant and costly deficiencies which are continuing and growing.

The most fundamental problem is the perception that the challenge, or task, or work to be done is primarily and basically a technology challenge, task or work which leads to the thinking that the required skill is the skill of “operating” or knowing how to use the technology.  This is a very wrong-minded perception.

Let me point out a few analogies to illustrate this point.

1. Teaching someone how to use carpenters tools does not make someone a carpenter.  They may be a wiz at knowing how to use a table saw but that does not mean they know how to make a set of cabinets you would want in your kitchen.
2. Teaching someone to use a word processor or text editor is not going to make them a speech writer, a novelist, or a poet.
3. Teaching someone how to use Oracle Financials is not going to make them an Accountant.
4. Teaching someone how to use a text editor or a printing press is not going to make them a journalist.

So, teaching someone how to use MVS, COBOL, DB2, Oracle, Sybase, C++, Visual Basic, SOAP, Word, Access, Windows, CICS, PowerPoint, Unix, Linux,  NT, Web sphere, Advantage Gen, .Net, COM, IMS, CORBUS, OO,  XML, UML, Component development (just to name a few pieces of information technology) is not going to make someone a competent business systems person that is going to be highly competent at solving the above list of problems.  More likely than not, they are going to continue creating more of those problems.  We have 40+ years of experience to prove this is true.

The second fundamental problem is the methodology employed by the information systems profession.  Every profession I can think of has developed a methodology for how they produce their product.  The challenge with the idea of a methodology is that there are very diverse perceptions of what a methodology is.  A methodology is a defined set of tasks that are performed in a specified sequence, in a specified manner (consisting of a set of concepts and principles, standards, techniques, conventions) which have been demonstrated to produce a specified, repeatable result.  Over time, practitioners of a methodology will evolve tools (technology) to help them do what they do.  Anybody who ever did anything has, to some extent, a methodology they use to perform their activity and if they do it enough times they will probably acquire some tools to assist them in doing their work.   The problem is that to change the result, you have to change the methodology.  In other words, you can’t produce a new or different result if you continue to use the methodology that is used to produce the existing result.

Accordingly, there are two essential prerequisites for performing any activity effectively and efficiently.  First, there is the methodology and, secondly, there is the knowledge and skill in the use of the methodology.

There are many IT professionals who are skilled at using their current methodology.  However, we know what the results are given the conventional ideas about how (i.e. the methodology) to develop business systems.  Enterprise management, the IT customer, is not happy with those results.  Enterprise management, mostly out of frustration and desperation, keeps searching for options.  This frustration and desperation is the primary cause for opting for:

1. Bringing in outside consultants, thinking that certainly the “experts” must have figured out how to solve these problems,
2. Using purchased packages, thinking that somebody must have already figured out how to solve these problems, and
3. Outsourcing IT, thinking that somebody else must have already figured out how to solve these problems.

Experience is showing that none of these options reliably produce solutions to the pervasive problems that have been with us for the last 40+ years.  The probability is that these options will only add to the extent of the problems.  The reason for the continuing frustration and desperation is due to the fact almost everybody practicing in the IT profession today is pretty much using the same methodology, therefore achieving pretty much the same results.  Enterprise management just ends up directing their frustration and desperation at different sets of people. 

Technology can be employed to enhance the effectiveness and the efficiency of performing the activity but, information technology typically does not provide for the inherent goodness or correctness of the process.  This may come as quite a shock to the “technology gods” and the technology marketers, but so be it. 

The problem is that key fundamentals of the methodology that have been used to develop business systems over the last 40+ years have not changed.  The general pursuit has been to develop new tools (technology) as a means to improve on the results and very little has been done to improve the methodology.

Well, we have a lot of evidence that is pretty convincing that the classical, traditional, or conventional methodology for developing business systems, or for that matter buying and installing packages, is defective and in dire need of change and improvement.  The time and cost to do either one is increasing at an unacceptably inflationary rate.  Acquiring and implementing business systems is most likely one of the very few activities in any enterprise that is not experiencing improving quality and cost effectiveness.  This trend has to be reversed.

ENTARCO has invested over twenty years analyzing, developing and testing changes in the fundamentals of how to build high quality business systems, cost effectively.  It has not been easy but the results are astounding.  Can you imagine what it was like to be the first person to suggest that the earth was round and not flat? Or that the earth was not the center of the universe?  Well, that’s what happens when you observe something that prevailing gurus or recognized sages don’t seem to see.

The business systems or information technology industry has been dominated by people who have been operating on the premise that the essence of their work was figuring out the processing requirements (specifying) and designing, coding, and testing applications logic and programs and getting those installed in production use.  Well, that is an important part of what needs to be done, but not the most important part.

The vast majority of the cost and time in creating business applications is expended in specifying, designing, coding, testing, and of course maintaining that stuff.  Consequently, that is what the majority of the people involved in the process were doing - specifying, designing, coding, testing and maintaining that stuff.  Naturally, that is where IT management has directed their attention because that has taken the most time and money and; that was seen as the gating factors in getting the job done.  Accordingly, much attention and energy has been invested in trying to figure out how to make specifying, designing, coding, testing and maintaining program logic faster and cheaper.  However, as it turns out, specifying, designing, coding, testing and maintaining program logic is not the root cause of their problems.  It’s the data!

Let me ask you this!  Why would you worry about how many lines of code could be written in a day when you were writing program logic to collect, store, maintain and access the same data over and over and over?  Think about how many times throughout your enterprise you have specified, designed, coded, tested and are maintaining person and enterprise demographic data such as names, addresses and phone numbers.  This is just a small part of the problem.  Someone once told me that they had specified, designed, coded, tested, and are now maintaining “Zip Code” 234 times in their enterprise!  Who cares how many lines of code you write per day if you are writing the same code 234 times!  Do you think this problem can be solved with components or object-oriented approaches and technology?  As long as the focus is on process and not data (meaning data is identified, designed and stored separate and distinct from its use) this problem will not only continue to exist, but it will get worse!  No wonder enterprise management thinks that “systems take too long and cost too much”!  They are right, they just don’t know why!

It turns out that to get at the fundamental nature of the business requirements it is extremely beneficial to focus on the objects of interest to the enterprise (as opposed to the processes), the data that described those objects, and the rules that govern how those objects relate to each other.  It is beneficial in the sense that the objects of interest, what needs to be known about them and how they relate to each other is fairly easy to determine, the results are very stable and highly reusable.  On the other hand, if you focus on the activities or processes you will be dealing with something that is much less stable and very difficult to manage for reuse.  Every known methodology, except for the MEA, focuses on the processes and not on the data.  Consequently, they create duplicate or redundant data, they create application databases, and they must build and maintain interfaces to move data around from one database to another, develop the processing logic over and over, and end up with excess maintenance effort and cost.  Sound familiar?  No wonder enterprise management thinks systems development costs too much, takes too long; and systems maintenance costs too much and takes too long!  They just don’t know why!

The data is so essential because it describes, or as you might observe, represents the objects that the enterprise is interested in and that which it manages.

The processes are the means by which we act on and manage those objects.  The objects are very stable or constant over time.  The processes are much less stable over time.  It turns out which processes an enterprise performs are fairly stable, how they perform those processes is more dynamic.  That is why the processes, along with the applications, are such a change and maintenance problem causing discontinuity and fragmentation of the enterprise.

The fundamental premise here is that it is paramount that knowing what is being managed takes precedence over how it is being managed.  Generally, you must know what you need to know before you can know it.  It is a very good idea to define the universe of what needs to be known before you embark on trying to manage it.  Wow!  You may think that it would be a monumental, never-ending task to figure out what the universe of what you need to know is!  Surprisingly, it is not too difficult!  It is one of those things that, if you know how to do it, is not to difficult nor does it take very long!  This is a methodology and skill issue, not a technology issue.   This knowledge, skill and competency are embodied in a discipline that is known as Data Management.  However, this discipline is in its infancy.

By the way, is anybody interested in one of the newest rages…Knowledge Management!  I’ll let you in on a little secret!  Knowledge Management won’t happen without some pretty good data management.  If you try, which you probably will, you may get something, but it will be less than you hoped for and it will be unnecessarily very expensive!

Are you interested in the idea of a “Real-time Enterprise”?  I’ll let you in on a little secret!  It won’t happen if you have data redundancy, interfaces moving data around from database to database, then trying to synchronize the data and then trying to maintain all of that.  If you try, which you probably will, you may get something, but it will be less than you hoped for and it will be unnecessarily very expensive!

Are you interested in the idea of a “Business Activity Monitoring”?  I’ll let you in on a little secret!  It won’t happen if you have data redundancy, interfaces moving data around from database to database, then trying to synchronize the data and then trying to maintain all of that.  If you try, which you probably will, you may get something, but it will be less than you hoped for and it will be unnecessarily very expensive!

The most overlooked, underestimated, ignored problem in the traditional process view of the world is the quality or the integrity of the enterprise’s data.  It is frightening to contemplate the quality of data in enterprises that has been observed to date.  Because there is typically no “enterprise view”, as opposed to an application database view of the data requirements, it is difficult to even detect the defects that exist in the current data in most enterprises.  Oh, there typically aren’t any easily recognized gross data quality problems; there are many errors of omission, inconsistency, incorrectness, timing, and in meaning and interpretation.  The process focus approach to systems is a major cause of this situation and it cannot fix it.  No wonder enterprise management thinks it has a data integrity problem, they just don’t know why!

Now, you may be wondering why this “data problem” has continued to grow and plague enterprises for 40+ years or so and nothing seems to have been done about it!  Well, the biggest reason is that the information technology industry, the peddlers of information technology, can’t make a market out of an enterprise’s data.  They can’t make it, they can’t package it, and therefore they can’t sell it!  Therefore, they are not interested in your enterprise’s data.  THAT IS YOUR PROBLEM!  Oh, they can sell you a filing system or a Data Base Management System (DBMS) as a tool to facilitate the storage and access of your data, but they cannot tell (some will try) you what that data is or should be.  THAT IS YOUR PROBLEM!  They will sell you a database design, but it will be an application database design not an enterprise database design.  Remember, applications databases are designed based on a usage of the data, not the inherent enterprise content and structure of the data, and they are the primary cause of data redundancy, data integrity problems, excessive program logic and maintenance problems.   As a matter of fact, these conditions contribute to the wealth and well-being of the information technology and services vendors, not to the wealth and well-being of your enterprise.  Beware; do not confuse information technology activity with progress.  Just because you have a lot of information technology activity going on in your enterprise, does not necessarily mean that there is a lot of progress going on.

The bottom line here is, stop creating all of those “data problems”!  If you don’t create the problems, then you don’t have to fix them!  Data Warehouses, Data Marts, Data Profiling, Data Cleansing, and to a large extent, Message Brokering, and middleware software are examples of activities and technology that largely exist to try to fix with the “data problem”.

However, there is good news!  The ENTARCO Methodology for Enterprise Architecture is a methodology that has resulted from recognizing the deficiencies in traditional, classic, or conventional methodologies and incorporating tasks, concepts, principles, standards, techniques, practices and conventions that eliminate those deficiencies.  The results are phenomenal!
 
We can demonstrate how to achieve:

1. Alignment - with the business requirements,
2. Integration - of data, process and operations,
3. Flexibility - to adapt to change,
4. Responsiveness - in a timely manner,

AND also dramatically improve:

1. Data integrity, and
2. Process consistency,

WITH the benefits of dramatically:

1. Lower cost,
2. Shorter lead times, and
3. Lower maintenance cost.

We can show how to acquire very high quality business systems at:

1. One-fifth the cost of traditionally developed systems, and
2. One-third the cost of purchased packages.

We can show you how to acquire very high quality business systems in up to one-third to one-half the time.

We can show you how many business changes can be implemented in hours, days and weeks instead of months and years.

We can show you how to create a systems environment with:

1. 80 to 90% reduction in maintenance costs, and
2. No interfaces moving data from one database to another.

We can show you how to create a business environment where your people spend a lot less time collecting, storing, finding, reconciling, correcting, analyzing and evaluating data and a lot more time working on business opportunities.

Why ENTARCO’S Methodology for Enterprise Architecture?
That’s why!

To learn more about how you can achieve these features and benefits for your enterprise, please contact ENTARCO USA Inc. at (614) 751-5078