EMS: How much does it cost? How long does it take?
Enterprise Management Services
“How much does Enterprise Management Services cost and long does it take to implement?”
My response to this question is, “How much has it cost and how long has it taken to implement Information Technology (IT), or Information Systems (IS), or before that, Data Processing (DP)?” The answer to this question is, “Well, IT is not a project and you don’t really implement IT. IT is a function that has many deliverables, and each deliverable has its own cost and schedule”. So it is with Enterprise Management Services.
To put this question in perspective, let me ask you a question. “How much does your enterprise spend on IT each year…an average?” Now, multiple that number by 10 to get a sense of how much traditional IT has cost your enterprise over the last 10 years. Adjust the average per year to compensate for changes over the last twenty years and then see what the approximate 20 year cost is. Consider this, it everything stays the same what will your enterprise spend over the next 10-20 years. Now consider what you have, how much it cost, and how long it took to get that which you now have. Is this what you and your enterprise wants or needs to look forward to over the next 10-20 years?
Now, consider this. Gartner Group forecast in 2010 that Application Overhaul will be the critical IT strategy for the next 10 years. They also go on to say that,“For many organizations, management of the application portfolio has largely been focused on adding applications according to business requirements. In many cases, little attention was paid to overlapping functionality or cost of integration.”
There is now an alternative that will cost a lot less and take a lot less time…Enterprise Management Services, the ENTARCO Methodology for Enterprise Architecture (MEA) way!
How much faster, better, and cost effective you ask?
- Up to an 89% reduction in applications development cost over conventional approaches.
- Up to 80% reduction in development time and effort.
- At least half the enterprise data reused at least 15 times.
- Extensive reuse of applications logic.
- Approaching 100% alignment with business requirements on first implementation.
- Dramatically lower maintenance cost, effort, and time.
- Unparalleled flexibility and adaptability to accommodate change.
So, you may ask, how is that possible? And, assuming that it is possible, how do you do that? The following discussion will provide with some insight into the answer to these questions.
First, we develop what we call an Enterprise Architecture Plan.
For those of you familiar with the Zachman Framework for Enterprise Architecture, this planning effort develops the enterprise artifacts (models) specified in Rows 1 and 2 of that framework.
This planning effort is performed using the ENTARCO MEA and it takes from 6 to 10 months, depending on the complexity of the enterprise. Complexity of an enterprise is a function of the variety and diversity of the products and/or services of the enterprise.
ENTARCO fix prices its services to lead and facilitate this effort.
This plan will contain the twelve models which will comprise the high level architecture of the enterprise and it will be complete and stable in terms of defining the scope and context of the enterprise.
These twelve models will be the rational guidance for the planning, identification, and scope definition for engineering and manufacturing highly aligned, integrated, agile, non-redundant, shareable enterprise databases and applications. This will replace the rather random, fragmented, and arbitrary approach to identifying enterprise applications and application database projects that has characterized IT planning in the past.
The MEA uses a concept that says that every enterprise has three categories of resources that it manages through a resource life-cycle. The three categories of resources are:
1. Primary resource – Revenue Generator = Product and/or Services
2. Supporting resources – Cost Generators = Labor, Money, Equipment, Material, Supplies
3. Aggregate resources – Allocations of Primary and Supporting Resources for Management Purposes = Organization, Facility, Project
The resource life-cycle consists of four phases.
1. Requirements – this phase consists of the processes performed to plan what resources and how much of those resources will be required.
2. Acquisition – this phase consists of the processes performed to acquire the resources.
3. Stewardship – this phase consists of the processes performed to inventory and take care of the resources in the possession of the enterprise.
4. Disposition – this phase consists of the processes performed to end the stewardship of resources in the possession of the enterprise.
The enterprises products and/or services determine the supporting resources employed by the enterprise.
Resources managed through the life-cycle determine the enterprise logical business processes.
Objects managed by the logical business processes determine the enterprise data requirements.
The use of these concepts guarantees a complete and very stable foundation on which to architect an enterprise; and on which to plan the logical sub-systems (components) of the enterprise that will need to be put in place to have a functioning enterprise. Therefore, this is a very rational basis for identifying enterprise logical business processes and the corresponding applications to support those business processes and the databases to provide for the enterprises data requirements. As John A. Zachman would say, “This is the way to rationally identify “slivers” of the enterprise for architecting, engineering, and manufacturing an enterprise. This becomes a very objective basis for allocating and prioritizing resources for the architecting, engineering, and manufacturing the enterprise.
Secondly, we proceed with the implementation of the Enterprise Architecture Plan
After the Enterprise Architecture Plan is completed, which is the guidance for managing the Enterprise Management Services function, individual projects for the architecting, engineering, and manufacturing the subsystems that constitute the system know as the enterprise, can proceed.
The schedule for each of these efforts will vary depending on several factors.
1. The size and complexity of the business process being architected, engineered and manufactured will be the primary determinate of the time and cost of the project.
2. A significant factor in architecting, engineering, and manufacturing an enterprise sub-system is the availability of reusable data and process logic. Accordingly, the time and cost of the first few sub-systems will be impacted if they are significant “data users” as opposed to “data creators”. If the early implementations involve using a lot of data that they don’t create, that will extend the time and cost of those implementations. However, with the use of the MEA, this turns out to be an investment that has a fairly quick payback. Because any “data work” done for any one implementation is available for reuse on all subsequent implementations all subsequent implementation times and costs are reduced.
3. As more enterprise sub-systems are implemented and more data and application logic is available for reuse, the time and cost for each implementation will decline relative to earlier implementations.
4. Because of the shared/reuse of data, we dramatically reduce time and cost of development by significantly reducing, or even eliminating the need for data conversions and interfaces
5. Schedules are always a function of time and available resources. To a limited extent, the time it takes to implement a component of the enterprise can be adjusted by increasing or decreasing the resources allocated to the effort.
For these reason, we know from experience that the time and cost to implement enterprise databases and applications are continuous reduced because each implementation provides a highly aligned and integrated sub-systems within an overall enterprise architecture. As such, each implementation leverages the investment made in previous implementations through its reuse of sharable data and application logic.
Now, for more on how we do EMS the ENTARCO MEA way.
First of all, we borrowed some concepts, principles, and practices from architecting, engineering and manufacturing disciplines that dramatically changed engineering and manufacturing outcomes over the last 100 years or so and applied them to the architecting, engineering, and manufacturing of an enterprise. A sampling of these concepts, principles, and practices are:
1. We changed the approach to architecting, engineering, and manufacturing an enterprise from a “job-shop” approach to a much more advanced “custom finished product assembled from standard components built to inventory, for immediate (almost) delivery” approach. (By the way, many industries go through an intermediate phase called “standard products built to inventory for immediate delivery”, but since we had the benefit of having been in the job-shop world and had already seen the “custom finished product” world, we accelerated the evolution a bit!)
It turned out that when we applied this approach to the architecting, engineering, manufacturing of an enterprise, we got a really big bonus. We do not have to build all the parts needed for every product we are to deliver. In our world, we can build the “parts” (data and process logic) just once and reuse it lots of times!
2. We have applied Six-Sigma Quality concepts to the entire process of architecting, engineering, and manufacturing an enterprise. This includes applying principles such as:
a. Design the architecting, engineering, and manufacturing processes to eliminate defects.
b. When a defect is discovered, fix it then. Do not let the defects get delivered to the customer. Also, fix the process to prevent the defect from occurring again.
c. Use quality parts to build quality products.
d. Remember: Quality if free, it is the lack of quality that is expensive!
3. Strive to reduce cycle-time. By continuing to reduce the cycle-time of every step in the process, we continuously reduce the opportunities for defects to occur and cost to be incurred.
Secondly, we stop doing a lot of things that take time, cost money, and cause defects. We stop doing the same data and process analysis, design, and development over, and over, and over, and over again. How do we do that?
We have learned how to build and maintain complete, correct, and stable yet flexible enterprise models of the data and business processes, and we build them once and reuse them lots of times. We collect and store one fact (piece of data), one place and reuse it lots of times. Our experience has proven that over half of the data in an enterprise is used at least an average of 15 times. We don’t identify and design half of an enterprises data 15 times or more and then store it 15 times or more and make the enterprise maintain it 15 times of more. That also means that we do not have to design and write the program logic 15 times or more to store, maintain, and retrieve the data 15 times or more…we just call it and execute it again. We do not copy the code and drop in another program. It the code needs to change for some reason, we only have to change it one place and we are done! This is one way we can dramatically reduce the cost and time traditional approaches incur in developing and maintaining applications and databases. What many people haven’t figured out yet is that the data an enterprise needs is pretty finite, but its use is very dynamic. People really, really like to use data over, and over, and over again. As a matter of fact, this concept changes data from being an expense to the enterprise into an asset that continues to provide a very high return on investment!
Caution: You have to know how to identify and design enterprise date so that it is complete, correct, available, and accessible in order to achieve these results. That is what ENTARCO has proven to be really, really good at!
Thirdly, since we build business process models and we management those models and the applications logic that is designed and developed to perform the business processes, it is relatively easy for us to identify chunks of logic that can be reused….over, and over, and over! Also, since the logic that is being reused is already tested and in production use, we don’t have to design it and test it, over, and over, and over again!
Fourth, we learned how to get very correct business requirements right the first time. This results in much shorter development cost and time, less rework (rework always costs more and takes more time; and nobody likes doing it either) and a lot less maintenance cleaning it up after it is put into so-called “production”. We actually design the enterprise’s business data and processes before we start what traditionally is called systems analysis or design. The time and cost to design enterprise business data and processes is small compared to the cost and time of designing and building applications and databases. We also figured out how to identify and design enterprise data and business processes independently and in parallel so that by the time we are done with both, they are both reconciled and complementary to each other.
We design the enterprise databases (which are non-redundant, shareable, with one fact, one place) before developers start writing the code. Therefore, the code that they write referencing the data (database tables and columns) is already determined to be correct, complete, and stable thereby practically eliminating any rework due to database re-design. This also is a major factor in achieving massive data reuse throughout the enterprise. Also, once the data required by the application is determined, we can quickly identify the data that is already in production and tell the developers which data to use and also the logic they can call to store and retrieve the data from the databases. Oh, and in case you are interested, we have had less than 5 cases of a “performance problem” which were solved with little compromise in over 15 years of production operations.
We design the enterprise data and the supporting enterprise database(s) to keep track of every fact over time without the use of history tables. Our very advanced temporal data modeling conventions provide for keeping track of what was true when (past, present, and future), and when did we know it. This quite naturally provides us the capability to use the data in its natural state to do all sorts of time-phase analysis such as year-to-date, inception-to-date, detail and summary comparisons; second, minute, hourly, daily, weekly, monthly, quarterly, semi-annual, annual summaries and comparisons, solve business and customer issues by being able to know and explain what happened when, who did it, where, and when did we know it.
These conventions and techniques dramatically improve the availability of high quality enterprise data, dramatically reduce the cost of using the data including reducing the cost, time, and effort to develop and sustain data warehouses and data marts when they are, in fact, appropriate and necessary.
Because we successfully reduce the volume of data by eliminating redundant data which is collected and stored, we reduce the cost of storing and maintaining the data. More importantly, our experience shows that our data modeling approach initially identifies more required elements of data than is discovered through traditional or conventional methods of analysis and design! This helps us promote the reuse of the data, eliminate data redundancy, and eases the path to program logic reuse.
We also reduce time and cost of development by significantly reducing, or even the eliminating the need for data conversions and interfaces. As an enterprise progresses through the development and implementation of more and more applications designed and constructed using the MEA; and the sharing (reuse of existing production data) of data becomes more extensive, the need for data conversions to populate new applications databases is eliminated. For the same reasons, the need to develop and maintain data interfaces among applications databases is nearly eliminated. (We have a case where four major applications have been built using the MEA and we have not built one data interface because the production data is shared by all the applications. This dramatically reduces the cost, time, and effort to develop and maintain enterprise applications and databases.
Caution: Yes, the initial MEA developed applications will require some data conversions and data interfaces to work within the existing applications portfolio. However, over time, as more and more applications are overhauled, modernized, or renewed, these interfaces can be eliminated. This is a situation where we provide a path out of the data conversion/data interface abyss, whereas the conventional or traditional approaches just keep making this abyss bigger and deeper.
Another way in which we can significantly reduce the cost and time to deliver capability to an enterprise is through our standard data and process models and database designs and application logic. Because of our extensive experience, we can now offer our customers “production ready” components of data and related functionality so that you don’t have to “re-invent the wheel” (data and program logic) again! This enables our customers to focus on those architectural components that are unique to them.
The big, strategic benefit of using the MEA is that fairly quickly, it will become faster and much more cost effective to replace existing applications and application databases that it will to continue to enhance, maintain, and operate them. The reason this result is achieved is because of the ever-increasing amount of reusable and shareable data and application logic; and the elimination of the need for data conversions and data interfaces dramatically reduces the cost of the next development and implementation effort. Yes, folks, it can and does keep getting better! This is a major reversal of the trend that is being experienced in the IT world today!
Douglas T. Erickson
President, ENTARCO USA Inc
©2011, ENTARCO USA Inc.
P.S. Implementing EMS is not a project. EMS is a transformation of IT for the 21st century. Just as traditional IT had many deliverables, EMS will have many deliverables. However, how those deliverables are architected, engineered, and manufactured will be dramatically different, compared to the legacy produced by what we know as IT. The difference is, EMS, the ENTARCO way, will deliver a lot faster, better, and much more cost effectively.