We do enterprise architectures, service-oriented architectures, and semantics. I suppose it was just a matter of time until we put them together. This essay is a first look at what a semantic enterprise architecture might look like.

What problem are we trying to solve?

There are several problems we would like to address with semantic architecture. Some of them are existing problems that are just not solved well enough yet. Even though many organizations intellectually understand what a service-oriented architecture is and what it might do for them, the vast majority remain unmotivated to invest in the journey to migrate in that direction.

Certainly we want the semantic enterprise architecture to address the same sorts of situations that the service-oriented architecture can handle, such as the ability to rapidly adapt new applications; to swap out technologies and applications at will; and to do so with commodity priced services and technologies. But let’s also focus on what additional problems a semantic enterprise architecture could address.

Dark matter and dark energy

As strange as it may seem there is mounting evidence that the knowable and visible universe, that is, the earth, the sun, the planets, the stars, the galaxies, and all the interplanetary and intergalactic dust represent some four to five percent of  the total amount of “stuff” that there is in the universe. We live in the froth of a giant wave whose presence we can only infer.

What makes up the rest of the universe is what physicists now call dark matter and dark energy. Dark matter makes up some 25% of the mass and energy deficit of the universe and is the primary force holding galaxies together, as the gravitational attraction of the masses of many stars and black holes is insufficient to do the job on its own.

Rather than the universe’s expansion slowing down since the big bang as the amount of mass and dark matter would suggest, apparently the universe is moving apart at an even faster rate. The propelling force has been dubbed “dark energy” and it comprises the remaining 70% of all the “stuff” in the universe. And so it is with our corporate information systems. We fret continuously over our SAP databases or the corporate data warehouse or the integrated database system that we run our company with, but this is very much like the five percent of the universe that we can perceive. It’s comfortable to believe that’s all there is.

But it just doesn’t square with the facts. Rogue applications, such as those built in Microsoft Access, Excel or FileMaker are the Dark Matter of an information system.  Like the cosmic Dark Matter, in some fashion they are holding an enterprise together, even though most of the time we can’t see them. Messages and documents are our Dark Energy equivalent: they are the expansive force in the enterprise. And like Dark Energy in the Universe, they are undetected by the casual observer.

What Does Enterprise Architecture Have to do with Semantics?

We ignore our information dark energy and information dark matter largely because at a corporate level we literally do not understand them. In our corporate databases we’ve invested decades of effort and typically millions and usually tens and hundreds of millions of dollars of implementation, standardization, training, and documentation in an attempt to arrive at a shared meaning for the corporate information systems. As we’ll discuss in other white papers, this has still left a great deal of room for improvement. Indeed, most of the meaning is shared only within an individual application.

Occasionally, corporations invest mightily in ad hoc semantic sharing between applications, under the guise of Systems Integration. But what we’re going to talk about today is the information dark matter and information dark energy and bringing them into the light. With the rogue systems, what we need to know is: what is the correspondence, if any, (and, by the way, it is usually considerable) between the rogue systems and the approved systems. More often than not, a rogue system is populated from either extracts or manual creation of data from approved systems. The rogue system is often created in order to make some additional distinctions or provide additional behavior or extensions that were not possible in the approved system. But this does not mean they don’t have a shared root and some shared meaning.

Occasionally, rogue systems are created to deal with some aspect of the corporation that, at least initially, appeared to be completely outside the scope of any existing application. You may have a videotape renting application or a phone number change request application or any of a number of small special-purpose systems. However, if they become successful and if they grow, inevitably they begin to touch aspects of the company that are covered by officially sanctioned systems.

What we want to do with semantics is to find and define where the commonalities lie in such a way that we may be able to take advantage of them in the future. For the unstructured data we have an even bigger challenge. With the rogue system, once we deduce what a column in the Access database means, we have a reasonable prediction of what we are going to find in each change record. This is because the Access database, while it may not be as rigorous as the corporate database, provides structure and validation.

Not so with the unstructured data. With the unstructured data, we need to find ways to find and organize meaning where every instance may be different. Every email, every memo, every reference document contains different information. The semantic challenge is to find, wherever possible, references in this unstructured data to information that is known at a corporate level. The approach here is almost exactly the opposite: in documents, people rarely refer to what we think of as meta-data or categories or classes or columns or entities — or anything like that. In documents, people refer to specific instances. They may refer to their order number in an email; they may refer to a set of specific codes in a reference manual; they may refer to a particular procedure in procedure manual. Our semantic challenge in this case is to find these items, index them, and associate them to the meta-data and even the instances that exist at a corporate level.

Semantic Enterprise Architecture

So what’s in the architecture? The Sematic Enterprise Architecture is still primarily based on Service Oriented Architecture concepts. We want to be able to communicate between largely independent applications and services using well-defined and corporate standard messages. These messages should be produced and consumed in such a way that allows at least some local change in their structure and syntax without breaking the rest of the architecture.

But we need to go considerably beyond that. We will need a meta-data repository that links the enterprise’s shared schema with a more generalized and, at the same time, more precise description of what these things mean. This meta-data repository will be populated by a combination of machine and human inferences from the description of the meta-data that exists in the many dictionaries and documentation bits as well as from the product of data profiling. Data profiling in the corporate systems will tell us not what we intended the data in our corporate systems to mean but in practice, from how we have been using the system, what it has come to mean.

This expression of the enterprise meta-data in a rigorous format is just the beginning or the gateway for incorporating our dark energy and dark matter. The rogue systems need to have their meta-data catalogued in a compatible fashion to the enterprise meta-data repository. This will allow us at least to know when the corporate systems may want to refer to the rogue system for additional details. Conversely, it creates at least some hope that the rogue system may have a defined interface to the corporate system and may be informed if things change.

The unstructured data will be incorporated using technologies that already exist, including text interpretation, first to find any specific nouns or events that are called out from the unstructured data. Using this information, the unstructured data can be cross-referenced to instances and by extension into the entire enterprise data network.

How to Get Started

This all sounds a bit incredible. And the endgame is likely a ways off. But we don’t have to go to the endgame for this to be useful. As Jim Hendler says, “A little bit of semantics goes a long way.” Even if we only pick a few topics to index in our meta-data repository, and even if we choose a few well-known rogue applications to cross-reference, and even if we only grab the low hanging fruit from our unstructured data, as many companies are already doing, we will still see considerable benefit.

Many content management and some knowledge management projects are aimed at using humans to perform this style of indexing on the reference documents that we often use in our organizations. But with a little extension this can go considerably farther. As it is, it’s generally an island unto itself. But as we’re proposing here the island can be extended and incorporated into the broader enterprise landscape.

Concluding Thoughts

We’ve barely scratched the surface here. However, many of the technologies needed to make this work already exist and have been proven in isolated settings. What are needed are companies willing to invest in the research and infrastructure in order to profitably include the other 95% of their information infrastructure into their enterprise architecture.

In many organizations, ROI is a euphemism for quick fix or short term payout projects.

I’ve come across a couple of articles recently on either the difficulty or the impossibility of constructing a Return on Investment (ROI) analysis on enterprise architecture projects, which, of course, we would take to also include service oriented architecture projects. While I agree with many of the authors’ points and frustrations, particularly in organizations with a policy of ROI-based project approval, I don’t completely agree with the assessment that ROI is not possible. The difficulties in constructing an ROI for architectural projects lie in two major areas: timeframe and metrics.

Timeframe Issues

In many organizations, ROI is a euphemism for quick fix or short term payout projects. It’s not so much that an architectural project does not have a return on investment but typically the investment is considerably longer than befits a quick fix project. Organizations that overemphasize ROI are typically addicted to short term solutions. While a great deal of good may be done under a shorter time horizon, there is also often a dark side to them. That dark side is that the quick fix is often implemented at the expense of the architecture. What remains after a long period of time is often an architecture of many arbitrary pieces. As a result, each succeeding project becomes harder to accomplish and maintenance costs go up and up. However, these weren’t factors in the ROI for the project and as a result the project approval scooted on through. Indeed, if there were no return on investment for an architectural project one would argue that we shouldn’t do it at all; that if we were going to spend more than we would ever save, that we should just save ourselves the headache and not do it. However, I and most people who give it serious thought recognize that there is a great deal of payoff in rationalizing one’s architecture, and that the payout occurs over a long period of time in increased adaptability, reduced maintenance, additional reuse, etc.

The ROI Denominator

Another piece of the ROI equation is the denominator. In other words, return on investment is what benefit or what return you got divided by the investment. One of the difficulties in justifying some architectural projects is that the denominator is just too large. Some architectural projects will overwhelm and outweigh any conceivable benefit. However, these projects do not have to be large and costly to be effective. Indeed, we find that the best combination is a fairly modest architectural planning project, which then uses monies that would have been spent anyway, supplemented with small bits of seed money, to grow the architecture in a desired direction incrementally over a large period of time. Not only does this reduce the denominator, more importantly, it reduces the risk because with any large infrastructure-driven architectural project there’s not only a large investment to recoup but there’s always the risk that the architecture might not work at all.

Getting the Right Metrics

The final problem, even after 50 years of software development, is that we’re still not routinely collecting the metrics we need to make a rational decision in this area. Sure we have a few very gross metrics, such as percent of IT spending to sales or proportion of new development versus maintenance; and we have some low-level metrics such as cost per line of code or cost per function point. But neither of these are much help at all in shining light on the kinds of changes that will make a great economic difference. In order to do this, we now need to look at the numerator of the ROI equation. The numerator will consist primarily of benefits expressed as cost savings relative to the current baseline. Within that numerator we will divide the activity into the following categories:

• Operational costs
• User costs
• Maintenance costs
• Opportunity costs

Operational Costs

Operational costs are the total costs required to keep the information systems running. This includes hardware costs: leases and amortization of purchased costs; software licensing costs: onetime costs and especially annual support costs. This also includes all the administrative costs that must be borne to support the systems, such as backup, indexing, and the like. In addition, we should include the costs required for direct support such as help desk support, which is required just so that users can continue to use the software systems as intended. This category of costs is relatively easy to get in the aggregate. In other words, from your financial statements you probably have a pretty good idea of these costs in total. In many organizations it’s more difficult to break these costs into smaller units, where the investment analysis really occurs. This includes breaking them down into application level costs as well as cost per unit of useful work, which we will talk about more toward the end of this article. An enterprise architecture can very often have dramatic impacts on operational costs. Some of the more obvious include shifting production from inappropriate hardware and operating system platforms. For example, in many cases mainframe data centers are cost disadvantaged relative to newer technology. Also very often the architecture can help with the process of rationalizing vendor licenses by consolidating database management systems or application vendors. There can be considerable savings in that area. An architecture project may be targeted at changing an unfavorable outsourcing arrangement or conversely, introducing outsourcing if it’s economically sensible. The longer run goals of service oriented architecture are to make as many as possible of the provided services into commodities with the specific intention of driving down the cost per unit of work. Without the architecture in place your switching costs are high enough that, for most shops, it’s very difficult to work a process of ratcheting down from higher to lower cost suppliers.

User Costs

By user costs we mean the amount of time spent by users of the system over and above the absolute bare minimum that would be required to complete a job function. So if a job requires hopping from system to system, navigating, copying data from one system to another or from a report into a system, transcribing, studying, etc., all of this activity is excess cost created by the logistics of using the system. These costs are much harder to gather because they are spread throughout the organization and there is no routine collection of the amount of time spent on these activities versus other non system mediated activities. Typically, what’s needed in this area is some form of activity-based costing, where you can audit on a sampling basis how people spend their time and compare that against “should cost” analysis of the same tasks. Even when the task has been off loaded to the end user, what’s called “self-service,” it still may be worthwhile to review how much excess time is being used. In this case, it’s not so much a measure of the resources lost from the organization but it may be an indicator that competitors may be able to take advantage of an effort difference and steal customers. Many aspects of service oriented architecture are aimed exactly at this category of costs. Certainly, all the composite application, much of the system integration, and the like, is aimed at reducing non value-added time that the end users spend with their systems. Implementing service oriented architecture as well as workflow or business process management or even process orchestration can be aimed directly at these costs.

Maintenance Costs

These are the costs of keeping an information system in working order. It includes breakdown maintenance, which is fixing problems that occur in production; preventative maintenance, which is rarely done in the information industry but would include re-factoring; and reactive maintenance, which is maintenance that is required due to changes in the environment. This category includes changes to the technical environment, such as when an operating system is discontinued and we’re forced to maintain an application to keep it running, as well as changes in the regulatory environment where a law changes and we are forced to make our systems comply. I did not include proactive maintenance or maintenance that is improving the user or business experience in this category as I will include them in the opportunity cost category. Maintenance costs are typically a function, not so much of the change to be made, but of the complexity of the thing to which the change is being applied. Most maintenance to mature systems involves relatively small numbers of lines of code. Especially when we exclude changes that are meant to improve the system we find fewer and fewer lines of code for any given maintenance activity. That’s not to say that maintenance isn’t consuming a lot of time; it is. Maintenance very often involves a great deal of analysis to pinpoint either where the operational problem is or where changes need to be made to comply with environmental change. Once the change site is identified another large amount of analysis needs to be done to determine the impact the change is likely to have. Unfortunately, the trend in the nineties to larger integrated systems essentially meant larger scope to search the problem and larger scope for the change analysis. The other major difficulty with getting metrics on maintenance is that many architectural changes eliminate the cost so effectively that people no longer recognize that they are saving money. One architectural principle that we used in the mid-nineties was called “riding lightly on the operating environment.” We argued that a system could have the smallest possible footprint onto the operating system’s API. In many ways this is the opposite way many applications are built. Many application developers try to get the maximum use out of their operating environment, which makes sense in the short term development productivity equation, but as we discovered the fewer points of contact you have with the operating system the more immune you are to changes in the operating system. As a result, systems we’ve built in that architecture survived multiple operating system upgrades, in many cases without even a recompile and in other cases with only a simple recompile or a few lines of code changed. The well-designed enterprise architecture goes far beyond that in the realm of reducing long-term maintenance costs. In the first place, the emphasis on modularity, partitioning, and loose coupling means that there are fewer places to look for the source of a problem, there is less investigation to do for the side effect, and any extremely problematic area can just be replaced. In this area, we will likely have to calculate the total cost per environmental change event, such as the cost to upgrade a version of a server operating system or, as we recently have history with, the cost when the environment changed at Y2K and two digit years were no longer sufficient.

Opportunity Costs

In this category I’m putting both the current cost to make proactive changes – in other words, cost to improve the system to deliver better information with fewer keystrokes – as well as the cost of the opportunity lost for not making a change because it was too difficult. The architecture can drastically improve both of these measures. In the first case, it’s relatively straightforward to get the total cost of proactive changes to current systems. However, we likely need to go much beyond that and look at change by types. For instance, what is the cost of adding additional information into a use case?  What is the cost of streamlining three steps in the use case into one?  Perhaps someone will come up with a good taxonomy in this area that would give some comparable values across companies. We also have to include the non-IS costs that go into making these kinds of changes. Not only does this include the business analyst’s design time but if it’s currently possible for analysts to make a change on their own, we should count that as development time. In the longer run, we expect end user groups to make many of these kinds of changes on their own; and indeed, this is one of the major goals of some of the components of an enterprise architecture. The other side, the opportunity lost, is very difficult to measure and can only be done by interviewing and guesstimate. But it’s very true that many companies miss opportunities to enter new markets, to improve processes, etc., because their existing systems are so rigid, expensive, and hard to maintain that they simply don’t bother. Also in this category are the costs of delay. If a proposed change would have a benefit but people delay, for often times years, in order to get the budgetary approval to make the change that’s necessary, this puts off the benefit stream potentially by years. With a modern architecture, very often the change requires no capital investment and therefore could be implemented as soon as it’s been well articulated.

Putting It All Together

An enterprise architecture project can have a substantial return on investment. Indeed, it’s often hard to imagine things that could have a larger return on investment. The real question is whether the organization feels compelled to calculate the ROI. Most organizations that succeed with enterprise architecture initiatives, in my observation, have done so without rigorous ROI analyses. For those that need the comfort of an ROI, there is hope. But it comes at a cost. That cost is the need to get, in the manner we’ve described in this white paper, a rigorous baseline of the current costs and what causes them. Armed with this you can make very intelligent decisions about changes to your architecture that are directly targeted at changing these metrics. In particular, I think people will find that the change that has the biggest multiplier effect is literally changing the cost of change.

Written by Dave McComb