Introduction
The article focuses on the key question – what does the business need and how to align IT with it? A clear understanding of business goals and imperatives is vital in implementing SOA, without which it is nothing more than a Sisyphean task. We need to understand business goals in the context of what services are required to drive the business. SOA is all about aligning the information, technology, and data with the business services to achieve enterprise agility, flexibility, and standardization. This article identifies some of the barriers in achieving IT alignment and provides concrete solutions to tackle these barriers. Please note that the solutions discussed here are from practical experience and do not claim to be the only solutions to the barriers described here.
Need for SOA
Many organizations are IT-centric and work in their own silos with redundancy, rigid architecture, and heterogeneous environments being all over the place. Business needs are poorly met due to lack of IT alignment with business imperatives. We usually compare IT alignment with business with the cliché “wheel alignment”. Business is the steering wheel of an organization and wheels are the IT platform, due to misalignment, the vehicle gets to its destination with either difficult maneuvering or jaded tires. As a result, the time to get to the destination increases or the vehicle incurs a severe damage. In business terms, the time to market is too long or cost of business is too high. SOA is not an IT initiative but an architectural style to align all the assets of an organization, including IT with business imperatives using services as a guiding principle. Since Service Level Agreements (SLA), flow of investment and customer experience dictate the business services, proper guidance and strong leadership is required for undertaking SOA initiative.
The Barriers
It is very desirable to polarize all assets in an organization with the services that the company is providing to its customers. It is all about being Service-centric. The following are some of the barriers most of the organizations have identified in delivering IT value to their business:
- Misunderstood business goals or objectives
- Lack of leadership or SOA champion
- Rigid architectures
- Multiple products in heterogeneous environments
- Redundant functionality provided by multiple silos
- High cost of ownership
There are many other challenges, but they ultimately fold into the ones listed above. The reality is, whether we are trying to achieve SOA or not, these challenges have been around for years. When we address these challenges in light of achieving SOA, not only is IT aligned with business but the entire organization.
The Approaches
Now that we have identified the barriers, let us discuss the possible approaches to overcome these barriers. A few points that would help discuss these approaches are:
- Business goals and objectives often translate into business processes. These processes either be automated or may have a human element to it.
- Business Processes are defined as collection of services contributed by different divisions of the organization.
- A pragmatic, iterative and an incremental approach should be adopted in defining the SOA strategy.
A clear understanding of the business goals is critical in delivering the right customer experience and augmenting the growth of the company. When business wants a yacht, IT should not deliver a rocket ship. A mechanism must exist to validate and measure the deliverables against the business goals. User stories are one such mechanism. User stories should be written by business and acceptance criteria must be defined for each user story.
Lack of a champion or a board undermines the long-term success of the SOA initiative. A committee must exist that is not only responsible for fostering the SOA initiative but provides guidance and governance. This committee is often referred to as the “Center of Excellence”.
When was the last time we were able to cleanly separate out the functionality desired by business from an existing product and share it with other products. Architecture flexibility is about seamlessly adding or removing functionality from an existing product without affecting the rest of the system. Loosely coupled architecture paradigm has been around for years now, yet we design architectures that are contrary to this style. Adopting a layered approach, programming with interfaces, separating data from the code can help achieve loose coupling.
Companies typically acquire products to increase their capacity or capability. These acquisitions make the IT landscape more heterogeneous and complex, not to mention sometimes resulting in redundant functionality. Customers accustomed to certain products offered by the company constantly want more functionality.
Interoperability becomes a huge impediment when this functionality has to be rendered to customers who are not existing users of the acquired product offering the functionality. If applications are constructed using loose coupling and a layered approach, functionality can be extracted out as a shared service or extended to provide interoperability. Figure 1 shows existing services from products being extracted and made available to other products by constructing a shared services platform.
We often come across companies that are IT-centric divided into multiple technical silos. Each silo is responsible for their piece that provides a service to the organization. However, there is a lack of collaboration among silos providing different solutions to the same problem. SOA strives to achieve a cohesive way for multiple silos to collaborate. This approach builds up synergy across the organization and brings a sense of ownership among the stakeholders whether they are business owners, IT managers, developers, or testers. Figure 2 represents multiple silos of an organization contributing to a shared services platform and other services that ultimately are part of some business processes.
The grouping of silos is achieved using the top-down approach, using business processes as the guiding principle. An effort is made to reuse existing services as much as possible. If these services serve multiple applications, then these services should be considered as candidates for being part of shared services platform.
In today’s market, where there is a constant pressure to deliver more with less, SOA advocates keeping a low cost of ownership. Companies should only build products that provide competitive advantage to the organization. This means companies need to invest more into enterprise architecture, upfront blueprints, and identifying the right applications to be constructed. Enterprise architecture should be cognizant of the business domain when adopting solutions for specific requirements. Considerations should be given to outsourcing peripheral services to strategic business partners. The focus should be on integrating services and delivering the solution as quickly as possible.
Conclusion
SOA is an architectural principle focused on aligning IT with business imperatives using services as the guiding principle. SOA is not an IT initiative focused on interoperability. There a multiple challenges in aligning IT with business and SOA helps overcome such challenges through proper guidance and governance. SOA breeds collaboration among silos in an organization and develops a synergy among the stakeholders of this initiative. SOA advocates reusing existing assets through shared services to eliminate redundancy. Architectures need to flexible and scalable to provide the necessary agility to the business. Enterprises need to have a clear understanding of the business requirements and build those products that provided competitive advantage. In order keep the low cost of ownership, consideration should be given on outsourcing peripheral services to strategic business partners.
References
- Executing SOA: a practical guide for the service-oriented architect - Bieberstein, Norbert.
- The art of service : how to develop, implement and enforce ITIL V3 best practices
Enterprise Architects are involved right from understanding business initiatives to ensuring those initiatives are well understood by IT and delivered within the scope and architectural guidelines agreed upon by different stake holders of the project. The diagram on the right shows the role of EA within the organization throughout the different phases of the project.
