Software Architecture and Information Technology Perspectives

Understanding Service Oriented Architectures

Over the last few years the word service oriented architecture has gained a lot of traction in the technology community. All the major technology vendors have come up with products that support or enable service oriented architectures (abbreviated as SOA). It therefore behooves us to understand what an SOA is and in doing so separate the hype from the substance.

Definition
Broadly defined, SOA is an software architecture concept that views the entire enterprise as a set of services. This set of services is responsible for supporting the business processes as well as the applications that support the business process (see the image for a conceptual view). Each service is responsible for providing one distinct, non-overlapping value-add. This service may be utilized by one or more business processes (or other services) to achieve its ends. One of the philosophical metaphors that makes SOA so attractive is that each service will be responsible for delivering on a negotiated set of performance metrics. Some of these metrics (roughly referred to as quality of service) include reliability, availability and performance.

Why SOA
Some of the reasons why an architect may choose to use service oriented architectures include

1. Reuse of IT investments
2. Flexibility in responding to rapid market needs: As the impact of global innovation and competition forces firms to evolve rapidly, they need to redefine processes. Outsourcing of processes by itself may help in reducing costs but does nothing to facilitate the provision of innovative services and products. The modularity provided by a service oriented architecture will enable an enterprise to be more flexible. Any process or service may access any other relevant service to provide the value it is responsible for delivering.
3. Technology agnostic: The services that support SOAs may be implemented with a myriad of technologies. Furthermore, they insulate a firm from the need to tie business processes to technologies. Thus a service may be implemented using either Java, C# or any of the other technologies available. They may be implemented with web services or other remote invocation technology. Finally, they may leverage a number of standards available in the market to ensure the longevity, robustness and maintainability of the service. These standards may include XML and SOAP.

While service oriented architectures promise to provide the traditional benefits of modular design the reason why this concept has caught on so quickly is that it promises to provide a means of accountability. Every service will be responsible for a quality of service to be delivered to its requester. Thus not only is a service responsible for delivering the actual functionality but also for the quality of that service. This quality of service will be negotiated to ensure that a service provider will be able to define, at service request time, what it is capable of providing. The figure illustrates this negotiated process.

Is SOA right for you?

The answer to this question lies in understanding two fundamental concepts of what an SOA is not.

1. It is not an integration mechanism
2. It is not a reporting mechanism

This understanding is critical to getting your mind around the problem. SOA is an architectural concept. It may be implemented by many technologies and its goals may be achieved by using different mechanisms. However, fundamentally it involves thinking of your enterprise technology infrastructure as a set of services acting together in a tightly synchronized manner (orchestrated) or in a loose fashion to support business processes. This support includes providing value from a correctness as well as quality perspective.

Having understood that one must then ask whether SOAs will provide any additional value to your enterprise. Each of the benefits outlined above will have a different quantifiable impact based on the nature of your business. For example, an enterprise in a heavily regulated environment will face fewer changes in its environment. However, when the changes do arrive their impact can be enormous. Similarly an enterprise that has standardized on a single vendor or technology and sees that as one of their primary competitive advantages may not value technological agnosticism.

The next question one needs to consider is whether the organization has the wherewithal to institute a service oriented approach to its technology infrastructure. Deciding what to leverage and what to discard can be a time consuming and laborious process. A structure such as a program management office must be in place to ensure control and visibility of the changes. Furthermore, a governance mechanism should be installed to resolve and drive standards, compliance and cross-functional issues. Larger organization typically have a lot of this structure in place albeit for a slightly different purpose. Smaller organization need to pick and choose how to achieve the same results with reduced resources.

Finally, one must determine when and how an organizations infrastructure can be aligned to the new architecture. Forcing change on an organization that lacks the skills, training or resources to execute the change can be demoralizing at best, devastating at worst. Nothing brings an organization to its knees faster than the loss of key personnel at critical times. Ensuring that the pace and scope of change is manageable will enable an effective alignment.

Conclusion

Service oriented architectures therefore hold much promise and take a broader view of what an enterprises infrastructure should provide. Aligning an enterprise along a service oriented concept can provide significant value. When selected as an approach, its application must be customized to an individual organization to ensure that all the pitfalls of change do not derail the effort.

(c) 2005 Vivek Pinto For more details please visit us at Wonomi Technologies

posted by vivek pinto @ 4:47 AM 0 comments

Outsourcing away your core competence

In an attempt to manage costs and create more agile enterprises, outsourcing stands out as one means by which firms have turned in enormous returns on investment. Outsourcing has been able to reduce fixed costs, convert them to variable costs and reduce an organization's inertia in a dynamic marketplace. However, success can be a poor teacher. There is a case to be made wherein too much of something that has worked can be bad for an organization.

Lack of a strategic perspective to outsourcing can result in firms losing their core competitive advantages. Take for example a major brand that sought to outsource its apparel manufacturing business. While moving those operations offshore resulted in markedly lower costs, it was met with rapidly deteriorating marketshare. The reduction in costs was accompanied with an increased lead time and more importantly a loss of knowledge about the processes involved in creating high end innovative wear. What got lost in the effort to reduce costs was the fact that the tension that existed between the designers and manufacturing personnel actually resulted in a better product. That creative tension could only exist in an environment in which both sides of the unit of the value chain had enough knowledge, skill and expertise as well as relationships to be able to meaningfully contribute and express dissenting ideas.

Another major corporation outsourced a large part of its information technology workforce. This resulted in projected savings of over a billion dollars over five years. However, six months after the transition of operations were complete a key fact became apparently clear - the business did not have a complete knowledge of the processes supporting the organization. While the business side of the organization has traditionally wielded a greater influence on the processes and policies that drive the organization, a lot has changed over the last decade. In an effort to get a technical solution to support a business, the business process has been modified to conform to what a technical solution can support. Furthermore, often the code within an implementation is the only form of easily accessible documentation of what the process is. These two factors combine to ensure that the an organizations process knowledge is diffused beyond just the business team. Consequently loss of key players results in a loss of process knowledge. The impact of this loss is compounded by the fact that finding replacements that have the business context as well as the technical skills to discover what that process was can be difficult and involve lead times anywhere from a month to half a year.

It is imperative, therefore, for an organization to take a close look at what it does, define what it does best and clearly demarcate the same. Any outsourcing effort then needs to be vetted against this list to ensure that no activity dilutes what is vital to the firm's core capabilities.

(c) 2005 Vivek Pinto For more details please visit us at Wonomi Technologies

posted by vivek pinto @ 12:41 PM 1 comments