Issue 2

What are the critical organizational issues that companies are experiencing as they embrace a service-oriented architecture (SOA)?

Companies that adopt SOA first have to deal with and understand how that new architecture changes the way that software will work, the way it is supposed to be built, deployed, managed, and even the way its cost is allocated across the people who use it. Those particular points drive a company to start thinking about how they have to organize to make sure the new things that need to be done actually get done by the organization in a consistent manner.

When a company looks at SOA, architecture is the key principle, because that is where the guidelines and the principles are actually set up. An organization has to be ready to ask, "How are we going to actually ensure that we are adhering to the guidelines, we are governing the guidelines of that SOA on the software side, and mirroring them on the organizational side?"

The first thing they have to do is make sure that they have proper architects. The role of the architect has to be very well specified and set out as a collaborative coordination point for what is going on in the service-oriented architecture.

The architect becomes a centerpiece. In other words, the architect must speak with the developers, business people, and the system administrators, to make sure the policies and guidelines that are laid out are actually being adhered to. If an enterprise makes the architect the center of that organization, then the roles of the other people around them, the developers, and the administrators and so forth, begin to change.

The roles and responsibilities for the developer change because some of the things they have to do in SOA did not exist before. An architect is going to be looking at principles and guidelines, but a developer now has to recognize that not only are they building code for a system, they are building a set of components, modules, or services, as in service-oriented architecture. Then those software services are going to have to be put together into valid applications or solutions to deliver to the end-users. This implies a new role; in fact, it mandates a new role, in that people must now focus on assembling the services into a set of working processes, as opposed to people focused on writing code. This is a new role and a new responsibility in the application development side of the organization.

In fact, those process-centric developers, will be the fastest growing group – by percentage – of developers over the next five years. They are going to grow faster than JAVA or C++ developers, and all of them by percentage of overall developers because we have to bring this new role in and build out the processes. That is one of the advantages of an SOA, being able to manipulate the processes, rather than having to manipulate the code.

There is also this idea that we have expansive modularity going on in an SOA, and a service-oriented architecture means that different parts of the organization are building different pieces of the final solution. Those pieces have to be coordinated and they have to share data. There has to be an understanding of how the data is going to be managed and how the services are going to be shared.

Who knows what they do, who keeps track of who is using them and when they need to go away? All those things have to be dealt with. This is a new role in the organization – the idea of a cyberspace librarian, or "cybrarian," a person or a group of people who keep track of all the pieces and parts that are being built in this service-oriented architecture. The pieces and parts include the services, objects, components, and policies that may be applied to how the services should be used. A policy for security or for authentication may be a part of it.

This librarian type role is a recorder, and it is not a part of the architect's role. This is a person who keeps track of things, as opposed to someone who helps define and influence the architecture itself. That is a new role and responsibility.

Then the idea of quality of service comes into play. Because an organization is going to a service-oriented architecture, one of the biggest transformations is going to be in delivering services that do what they are supposed to do, when they are supposed to do it. In other words, quality of service is more important now than the services that are actually delivered because quality of service is what determines whether someone can actually use what has been delivered.

The organization has to be ready and able to stand up and say, "Ah, we can track, manage, and deliver or guarantee delivery of a certain quality of service." In some organizations that may mean, actually bringing in or using part of the staff to be service providers, to become a service provision organization, as opposed to an application provision organization.

Two other issues come to mind – ownership and distributed transactions. Who owns what? Who owns the data, services, and processes, and how does one bill back for those processes? Who is responsible for the system that those processes run on? In terms of distributed transactions, an enterprise has processes that span organizations, business applications, computing systems, and even companies. And you have to understand when you are doing this transaction across a lot of different boundaries, how are you going to handle that? So let us take those two together.

First, ownership of business and data have to be actually associated with the ownership of the process – not the data, not the technology, not the service, but the process that the service enabled – and it must be a responsible owner for this process within the organization. That owner must be able to say, "I know what this process does. I know what value it delivers to the company and to our customers, and I will take responsible ownership of that to make sure that it does deliver." Then there is a business owner, a person who says, "I know what this process does from a business perspective in our company and I will take responsibility for making sure it does that." There is also a technical owner who, "I know how this thing does what it does, from a technical perspective, and we will be responsible for keeping it running."

Having those three responsible owners in the organization results in the ability to be process-centric – to know what the processes do, who gets them, and what to do when they fail. Without that, an enterprise is basically searching in the dark, because there are many processes out there that will be acting outside of anyone's control.

How are organizations approaching the development and enforcement of guidelines for building services that are going to be shared across departments and business units?

Organizations that are trying to enforce the guidelines of that architecture are doing it in a number of different ways. One is through the idea of an integrated policy group, which comes together to look at the guidelines and processes being used, and to share information about how they need to change. For quite some time we have had in the integration space, an integration competency center, which had a similar purpose for application integration. In the service-oriented architecture world, we need to look at an SOA competency center. This is really an extension of the Integrative Policy Group (IPG) idea, specifically in SOA.

In this center, one can use organizational structure, guidelines and rules, peer-to-peer pressure to keep people basically on the straight and narrow, assuring they follow the architectural principles, and make sure the guidelines are in place. There is also the idea that this can be done in software. One can begin to bring in a set of frameworks that are going to actually enforce the guidelines for how services are used when they are out there on the system, and thus, imply certain enforcement points for how services are built when they are actually going to be shared across business units.

The first example that comes to mind is when two or more different entities, companies, or business units need to share information through a set of services. They are going to have issues of coordination. When do I get access or not get access? What can I see and cannot see? Did the message get from me to you? In the real world, one might see a situation where one company is trying to ensure that another actually received an order, processed that order, and then sent a response that the order was processed and can be invoiced or billed.

Now, the consumer or the company that is actually placing the order sends that to the provider, the company that is actually receiving the order, and says, "Here is the order. Verify to me that you received it." Well, there are guidelines that need to be followed there – the document types; the access that the consumer has to the provider; do they have the authorization to send that kind of an order through? And if they do have the authorization, do they have the authorization to see certain information about that order that comes back, like customer ID or credit numbers that maybe associated with it.

Those are governance issues that entail the following questions:

• Who gets access?
• Do they have the proper security?
• Do they have the proper rights?
• Do they make sure that the message has gotten from place to place?
• Do they make sure that they got there in a certain amount of time?

Those are two of the ways that people are actually approaching the development and enforcement of these guidelines. There is also the idea that there must be a blurring of the responsibilities of the developer, the architect, and the deployment environment. Because we are seeing an overlapping of these responsibilities, developers are going to be designing things and maintaining things at run-time, and the areas they maintain will increasingly be rule and processes.

Rules are the constraints or the decision points that have to make decisions, and processes are the execution paths – what do we do based on a given decision? Those two areas happen at design time and at run time. So developers have to work with architects and system administrators to make sure the system is doing what it is supposed to do, not only when they build it, but also while it is operating. Plus, a service-oriented system is potentially a more adaptable system, and that requires ongoing, iterative, interaction with that system to keep it alive. When we do that, we actually have a much more comfortable ability to deliver the right systems to the right people.

How should organizations promote the right level of service granularity at design time? Are there other design-time elements that can help insure successful SOA adoption?

Certainly there are ways of deciding what the granularity of services need to be -there are some good things that have happened, and there are some bad things that have happened.

One of the bad things is that organizations have taken programmers, who are used to doing extensive coding – both object oriented and component based programming – and they have said, "Here is some service mechanisms. Now go out and build me some services." The first thing the programmers tend to do is wrap every method on every object in the object-oriented environment as a service. This is an approach that leads to far too much granularity. Too much fine-grained use of a system means the customer has not really gotten the benefit of services because they are having to look at every object and every method on an object as an independent piece. That leads to more complexity, not more productivity or efficiency. Hence, too fine-grained is bad.

A second way people go is too large-grained. They take an entire application and say, "Okay, we are going to wrap this as a service. You can send your name in and it will do some processing and then send you a result." This causes problems because now it is too monolithic, not flexible enough and broken down into enough pieces to be able to reuse parts of the system, or to be able to make sure that the parts can be interchanged within different systems.

The rule of thumb is to look for services that are going to be used in at least two different scenarios. In other words, the enterprise does not want to look for something that is only used in one place. To be clear, that does not mean services can never be built that are only used in one place – sometimes those are the best. If I want to be able to build a service that inquires of a database system where I can only do that inquiry in one way, there is nothing wrong with that. I just do not want all of my services to be designed based on that principle. Rather, the principle is, find at least two reuse scenarios, where it can benefit your business to actually use the service interchangeably in multiple systems, or as duplicates of one another so that your people can basically reuse the one without rebuilding them.

The second area is to look for services that are going to cross boundary, where a service implementation is created that will get users through a firewall, or between companies, systems, or business units. If, in fact, the service is going to be used only natively within one technology environment, then ask yourself, "Why would I build a service from this?" If it crosses boundaries, then it will tend to have some value proposition that goes beyond just the use in that system, and it may wind up being at a much better level of granularity because of that.

Another area is to examine the existing assets that an enterprise has in their system and make sure they may have transactions in the Customer Information Control System (CICS). In fact, the recommendation I have is that any organization with a large mainframe set of resources should immediately create a foundry of services. Look at all your services, transactions, screens, and the data in that legacy environment, and say, "Which ones of these are usable in a larger context – outside of the legacy environment, that may be used in multiple scenarios as was mentioned?" These are prime candidates to turn into services; but again, watch granularity. Every transaction need not be made into a service, just the ones that could be stitched together into a larger business process.

Services should ultimately map to the business functions they support. The level of granularity is really going to be designed on that, and one really are trying to get a greater degree of reuse or to reduce the amount of coding one is going to have to do in building systems moving forth into the future. This is one of the key areas in the difference between interoperability and integration. When we look at integration, we have spent a great deal of time talking about integrating systems and putting them together to make systems that did not previously work together, and function properly in the same context. The advantage of a service-oriented architecture and interoperability is that one does not have to change all the systems to fit one another, one has to change the systems to fit the standards around the service-oriented architecture.

As organizations adopt SOA, it represents a move away from centralized data centers and toward a more distributed model for encapsulation of business functionality, and often encompasses a change in the structure of how data is shared across the organization (integration of customer records, for example). How are organizations dealing with this transition today?

That question is a real mouthful. So is the answer, in that companies that are seeking to go with a distributed style, and that are looking at a service-oriented architecture, are immediately faced with two levels of complexity: (1) the complexity of distribution of data systems, people, and processes; and (2) the modularity of that distribution. That means there are myriad moving parts.

Think about it. If we have a system with numerous moving parts, but its maintenance and its use are distributed across a wide boundary, then we have something that is very difficult to maintain.

However, companies with such a system can benefit greatly from it, if they follow some guidelines. First, we have to understand that a distributed environment does not mean a chaotic environment. The distribution of that environment is held together by a set of standards; a set of standard ways of doing things, a set of best practices that go along with it. In an SOA, the set of standards start with the standards around how one encapsulates a service – how the services are actually described, how everyone gets access to them, how they are called, and how they tend to respond across the organization. If those mechanisms are adhered to, distribution becomes just another aspect of how the system tends to work.

So adopting SOA actually yields benefits in working with a distributed environment, because services are intended to be called remotely, whereas, in a traditional application, the functionality of the application must be called locally. The services are also loosely coupled, meaning that the consumers that talk to them do not have to adhere to the technology that was used to build them. They are loosely coupled in the way that they are called because one can call them with a message that is an accretive message. Also, they are loosely coupled in the way that they are described – one can look at the description of a service much more close to the time that one actually needs to use than in a traditional system. They are loosely coupled in terms of what kind of distance there needs to be between the caller and the receiver, and that is this remoting aspect of a service-oriented architecture.

SOA in itself helps an organization move toward a more distributed operation that a traditional centralized data center would do. This leads to the change in structure, of how the data is shared and how the services are shared across the system. Because it is a distributed operation, the data can certainly be kept closer to where the services are provided, but the distribution suggests that data needs to be synchronized across distributed parts of the organization or the system.

There still is a need to decide where the data will reside. Will it be in a centralized data store or in a distributed data store? An answer to that is, now there is the opportunity to break data out into the parts of the organization where it belongs. Rather than keeping everything in a centralized place, several sub-data centers can be used to keep data this relevant, based on a certain amount of time, or relevant based on a region of the planet, or relevant based on the kind of business that is being done with that data. It can be moved wherever it is needed, because distributed access to services includes distributed access to data. Also, much of this data is read-only when one needs a distributed access to it, so it can be moved around.

This changes structure from a centralized structure to a distributed structure. However, history tells us organizations shy away from distributed-based data. Keeping them synchronized and up-to-date across all the distributed stores is no simpler today than it was 10 years ago. We will likely stay with a centralized store of based data. However, in an SOA, information moves around the network, and the distribution of information is actually as important as the base data that is being operated on through the processes. That information is being distributed today in an Extensible Markup Language (XML) form, which gives us a way to share data across the organization that is unprecedented from traditional data storage system. Data can be shared and transformed from one form to another, transmitted over shared protocols, and it is a standard way of delivering that data from place to place. There are many different advantages of an XML style that allows us to interoperate or collaborate with data, more than we have before.

The form that data takes can be closer to a document style, a form of information that can be usable at the other end. The synchronization or the updates of data can be done in a more consistent fashion now because of an XML style. There is also the ability to transform that data into a set of workable documents, a set of policies that carry metadata, which allows us to understand the data much more effectively. We can create schemas around that data and say, "Not only is this data coming your way, but here is a document that explains it to you." When we get to that level, sharing information is the key, as opposed to just sharing data.

In a distributed environment, XML does not solve every challenge, but we can get a better, stronger, more total view of our customers because we can begin to look at information about them and metadata that explains that information. In addition, it allows us to begin to govern this data movement around the network because we can transform it from whatever form it is in, to whatever form it needs to be in, much more readily than we ever have.

So in this context we use the phrase, 'creating a document of record.' This is a central place of storage or a set of documents that are seen as the definitive location for a bit of information that is passing through the network. This is all enhanced by the ability of a company to use XML data storage, and to distribute that information widely across a global network.

How can a "center of excellence" or "competency center" best enforce the guidelines and restraints that have been set forth to help achieve an organization's SOA objective?

The biggest problem with a competence center enforcing guidelines is that most parts of the organization tend to rebel against guidelines that they did not create themselves. This is not new, it is not new with SOA, and it is not going to be solved any time soon. However, there are some best practices that seem to work.

First, an organization that is a competency center should be seen as an organization that is a coordinative, not a controlling body. If that organization puts out guidelines that say, "You must do things this way in all cases," there tends to be a rebellion. If on the other hand, the organization says, "Here are a few different ways of doing things that we accept. What we ask is that you adhere to one of these, but if you need to diverge from it, then we need to be notified of that well in advance." This is a coordinating effort to further say, "We are going to examine the choice that you are going to make, and we are going to give you back recommendations as to why that choice would be good or bad, and why you might want to make a different choice." Not only that, but we can share that recommendation and your recommendation with the other parts of the organization.

Now what happens is, the enterprise expresses a willingness to accomplish to the competency center's directives and goals. The enterprise is willing to expand their view, if the competency center is just willing to reach out and help them understand why their view is better than the others. If not, management must step in and say, "Look we have given you a fair hearing, and we have invited you in and you have refused to do that; now we are going to bring down the hammer."

However, bringing the hammer down is the wrong way to get this done because eventually someone figures out a way to take that hammer out of your hand and start beating you with it. That is something that must be avoided. You want partners, not people who are trying to rebel against what you are doing. So set guidelines and a set of standards -note, I say a "set" of standards, not a single standard. Many organizations spend time trying to get to one single standard type of software or single standard type of hardware to deliver, when in fact they should come up with a few different choices, and this is easier to deal with.

They also have to really look at this competency center and say, "We will monitor violations; we will not necessarily enforce them. We will cajole, reason, and suggest," but ultimately, management must be the enforcer of guidelines, not the competency center. In fact, if that kind of approach is taken, then this group becomes an asset for all parts of the organization, as opposed to a detriment.

Using technology choices is a great way to do this. Standardizing on a set of protocol standards, a set of hardware/software standards, and an enterprise service bus is a great example in the service-oriented architecture. The enterprise service bus is the Geneva of software. It says, "We will give you a standard container for how messages are exchanged in the organization, and for some of them how messages are transformed, but we will give you that ability without asking you to give up your existing software connection."

In other words, "Our enterprise service bus will allow you to connect in with different types of software, and we will handle the message exchange for you." Now that is a basic simplification of a what an enterprise service bus is, but certainly, it carries with it a technology solution to the type of approach that I have mentioned for the competency center. That is, it gives a set of standards and a set of options, and asks that people try to adhere to it. Because the enterprise service bus has made it as painless as possible for people to adhere. If they need to go somewhere else or do something different, then they can give notification and be accommodated.

So technology and this cooperative, coordinating attitude are combined to take a company much further than a controlling center, which is called a competency center in the organization.

What technologies can be applied to ease enterprise transition to SOA from an organizational perspective? Enterprise service buses (ESBs), directory services, repositories, etc.?

All of the technologies you mentioned – enterprise service buses or ESBs, directory services and repositories are certainly useful. The question is, how are they useful? And how do they translate to organizational value?

Look at the enterprise service bus as middleware for middleware, a way of connecting different kinds of middleware together. What is happening is, you are saying that organizationally, we are not going to ask you to change the guidelines and practices that you have. We are going to connect you to this, and we are going to interoperate between your guidelines, practices, and policies, and the practices and policies of others. With directory services and repositories, it is the same type of situation.

Consider repositories for a moment. When building a service-oriented architecture, one of the biggest problems is service. There are going to be thousands, hundreds of thousands of services eventually, in that service-oriented architecture. The value propositions are clear; one is reusability. I do not have to build it again, and if I can use it over and over again, I should save money to save time.

Secondly, look at the close tie between what the business requires and what the software does. Embodied in the service, a business process is easier to understand for the business.

Third is the ability to do more dynamic access to systems, so that the system is not just set in stone when the developer finishes. You want to be able to come back and say, "I need to change this process a little bit. I need a new version," or, "I need a new set of inputs to go into it."

In the service-oriented architecture, you can facilitate that much more quickly than in an architecture where you would have to go back to the programmer because now you can say, "I will switch out one service for another service that does it just a little bit differently." That can help an organization because it is quicker to get to the kinds of changes you need, so you can adapt more effectively.

There is this idea of distributed and federated environment. In a distributed environment, we talk about the services being able to be deployed wherever they are needed, because they are modular. They are loosely coupled. They are not tightly coupled to the server that you are sitting on, the system that they are running on, or the consumer that needs to use them. They are federated. They can be delivered anywhere and can be used by anyone in a joint effort to deliver a system.

This whole idea of technologies really helping an organization transition to an SOA is certainly there. However, the problem is not usually the technology to help them get there, it is the ability of the culture of that organization to adapt to the style that is going to be used. So any technology provider has got to say, "Wow, our enterprise service bus or our repository should go along with a cultural statement."

In conclusion, a reuse culture is supported by technologies like enterprise service buses, repositories, identity, and federation. However, it is the culture that is essential to this, and the technology provider must be ready to tie that cultural idea into the technology delivery.

How does process-centricity affect implementing an SOA?

The answer to this can be stated very boldly and very simply. If a company is not process-centric, it will likely fail in its first attempt to implement an SOA. Now the question that comes out of that is, what is process-centricity, and why would I fail if I do not have it?

Process-centricity is a fairly simple concept but very difficult for most companies to actually implement. Process-centricity says that a company is aware of the existence of the processes that matter most to that company's existence and health. It says that it has responsible owners for those processes, and that those owners act on a daily basis to make sure those processes are actually delivering what they are supposed to deliver in a right quality of service.

Now you go to most enterprises and you ask them, "How do your processes for order-to-cash work? How do your processes for delivering products on time work? Who do I go to ask that?" Well, there are 50 people you have to go to, because there is not one responsible owner. No one person can give you the exact step-by-step description of how those processes work, what systems are dependent on them, what would happen if they failed, or how you actually get it back up and running quickly if they fail? Companies do not know this information. That would be like going to a doctor's office and the doctor saying, "You are very ill. " You ask him how he figures that out and he answers, "I do not know. I just kinda guess."

That is exactly what many companies are doing. If you ask, "Which processes are the most important processes to the future health of my business?" then your answer should be, "We definitely know which ones they are. We know because we measure them. We measure their impact on our customer relations or on our bottom line profitability."

If you are not process-centric, then you probably are building processes that do not exactly do what you think they do. So you cannot really guarantee a quality of service, because you do not really know exactly what you are delivering. If you are not process-centric and you are not tracking, how well are you doing it? You cannot really say what the true impact of your technology investments are, nor can you say what the true impact of going to a service-oriented architecture and building process into the systems is going to be for you. All of it is a gut reaction, and that is something that is very dangerous for a company that is depending on a service-oriented architecture.

What about the organizational impact on the development team-what is the impact of SOA on project lifecycles?

This is tough one. Organizations that do development for SOA have several issues that they must face. We have defined the term SODA as Service Oriented Development of Applications to indicate the concepts that fit the development of the impact of an SOA. The impact of SOA on the projected lifecycles is also another one that needs to be examined. Let us take that one first.

The impact of SOA on projected lifecycles is that it can improve or shorten the time to market, or it can actually make things worse. It depends on the approach. If you approach it in the right ways, it will generally improve things. When you look at this from the point of a developer and the quality assurance people in an organization, we implement a service-oriented architecture to design, build, implement or deploy, maintain cycle -as a lifecycle of a set of services – and include a quality assurance step. It has to include some testing to ensure it does what it is supposed to do. In an SOA, though, there is a problem because if you actually deliver a set of services without knowing who the consumers of those services will be, you have a difficulty in ensuring any quality assurance (QA) process.

Say Sally creates a service, and John, Kim, Karin and Steve use that service to build their next billing system and their next taxation system. However, Sally does not know the other guys are using the services because there is nothing in the services to tell you who is consuming your services. When there is a change to Sally's service, how do all those people know the change occurred? And if they do not know, how do they test their systems to make sure they are still working?

This is an issue that changes the way you think about designing and deploying systems. In SOA, you have the number of services, times the number of change, times the number of consumers of that service, times – well, you get the point. Quite frankly, what you have got is three things that need to change, and three potential unknowns. You do not know when the changes happen, who they affect, and how many of them there are going to be. There are going to tend to be a lot more of them in a SOA than there would be in a monolithic system. The reason for this is because in the development of an SOA, you use an iterative process that is a biological evolution of a system, rather than the building of a machine. These systems must be changed several times with a number of small changes that adjust them slightly to fit the quality of service you are trying to deliver, much like a biological system.

So developers tend to embrace different models for programming – in extreme programming models, iterative lifecycle models, declarative programming, visual programming models that use the declarative statements, and generation of the code underneath. This means that the development focus moves from lines of code up to process-centricity, and up to process-centric developers who build processes. They do not know how the code works underneath. They do not know how the JAVA code is put together. All they know is, this process handles a step, or this service handles a step and a process. I call that step after I have called another step, and before I have called a third step. When I have done that, I have enabled solutions for the business. I have to check the level of inventory – that is a step. I have to be able to ask, "What is our policy for this level of inventory?" – that is a step. Plus, I have to able to do a reorder on that inventory if it fits the policy. So those three steps have to be brought together. That is what the process-centric developer cares about and not the functionality that underlies it.

The organizational structure requires that you are going to have to put in these new process-centric developers in between your coders and your business analysts. That also carries with it the need to support larger QA teams or more frequent QA processes. It brings with it the need to be able to understand the rules that are going to be applied to processes, not just the processes themselves, but what the rules are that have constraints on them.

For example, if the inventory goes below 500 units, then do a reorder. Well, should that rule change frequently? And if so, who does the work to change it? A business person? A programmer? Those are the decisions that have to be made in the organization.

Lastly, programmers in the IT development team have to be much more closely aligned with the architect and the systems administrators. Because of the operation of a system, a program is never finished in an SOA world. It is like the Sagrada Familia, the church in Barcelona designed by Gaudi that was never intended to be finished.

This is the nature of SOAs – they are never finished because they are always being maintained, and the design time/run time breakdown is really key to knowing that programmers are no longer just coders. They are actually operational maintenance experts. They change the system as it is being operated, and that is going to require different mechanisms for testing because you must have simulations of services, to simulate their behavior, not just the connectivity or the logic execute.

And lastly, you need to have a very strong feedback and interaction mechanism. There must be information flowing about these systems all the time, or they will tend to stagnate, and you will not get the reuse benefit, nor will not get the rapid flexibility that you might otherwise expect from these systems.

An SOA opens the door to many successes, to a system that behaves more like people behave, more like the business behaves, and is more closely aligned to what the business needs to get done. It is more flexible and can certainly be more easily distributed. However, it can also open a can of worms that will be filled with problems like the proliferation of too many fine-grained services, not enough collaboration between the development teams, no ability to test or maintain the systems and keep them running from change to change. All of these problems must be solved if someone is going to be successful with an SOA in the long term.

Source: Gartner