Using enterprise architecture with SOA helps in achieving business-IT alignment
Many IT projects have gone off track as a result of the lack of effective business/IT coordination or a shortsighted strategy. IT leaders often struggle to justify investments in projects when they do not have past evidence to support the claim that implementation of a particular architectural approach will add value to the bottom line of the organization. In the current business environment where organizations are struggling to achieve revenue growth and profitability, it is even more difficult for IT leaders to secure funding for such initiatives.
Enterprise architecture (EA) and service-oriented architecture (SOA) have the same objective of aligning business and IT, albeit from different perspectives, so their relationship should not be hard to understand. However, very few organizations have exploited the synergies between EA and SOA to achieve the true business value these two architectural approaches can provide.
EA and SOA initiatives should not be run in isolation or in parallel
Organizations that focus only on SOA run the risk of ignoring the aspects of EA that are mutually exclusive to SOA. For example, while SOA provides a flexible approach to the integration of different services, organizations cannot afford to ignore the importance of covering other integration needs at the enterprise level, such as point-to-point interfaces. Too much reliance on SOA can hamper the evolution of an organizationâ€™s IT strategy, because in most cases SOA would then be used as a solution for issues that would be better handled elsewhere. Similarly, if EA initiatives are run in isolation, organizations will fail to reuse existing policies, infrastructure, and artifacts associated with SOA.
It is also important to understand that EA and SOA initiatives when run in parallel can result in inefficient utilization of IT resources. In many cases, the lack of interaction between separate teams focusing on EA and SOA initiatives leads to a lack of understanding of the relationship between EA and SOA. As a result, two distinct yet connected initiatives end up following contradictory information models and system management policies. In order to ensure that EA and SOA initiatives stay on track and deliver the desired business value, organizations should first identify SOA-specific elements of EA and only then should focus on what is not covered by SOA.
A complementary approach facilitates business-IT coordination
While enterprise architects have complete ownership of EA initiatives, they are often not involved in other associated initiatives, including SOA implementation and upgrades. On the other hand, solution architects are only concerned about the objectives set at the start of SOA implementation and pay little attention to the evolution of EA. As a result, there are major differences in what enterprise architects want to deliver by following a service-oriented architectural approach and what is actually achieved through SOA implementations.
Service-oriented enterprise architecture (SOEA) is an enterprise architectural style that uses â€śservice orientationâ€ť (by virtue of enterprise-wide service architecture) as the entity aligning business and IT at the architectural level. SOEA uses services as the foundation for promoting the reuse of existing functionality, artifacts, components, business logic, and applications. A successful SOEA implementation calls for a larger role for SOA, extending well past the functional relationships that exist between the different architectural domains of EA and SOA.
A less disruptive and more practical approach to achieving a successful SOEA implementation starts with the realization of an enterprise-wide SOA. In the starting phase of SOA implementation, the high-level conceptual view provided by EA should be used for strategic planning purposes. Service consumers should provide a clear picture of the business requirements so that IT has a good understanding of the objectives behind SOA implementation and how these can be helpful in solving existing and imminent business problems. After becoming fully aware of business needs, IT must ensure that existing resources are exploited for the creation of new services and functionalities, and that duplication in the development process is minimized.
The actual implementation phase should involve the application of a bottom-up approach. This will provide IT management with an opportunity to align the underlying assets with the needs of the actual consumers of services. This approach also ensures the early identification of gaps if there are any. Line-of-business (LOB) management should conduct regular reviews to ensure that SOA implementation is on track, and a top-down approach should be used to gauge the standing of the modular architecture against the expected outcomes. The IT organization must then be informed of any perceived shortfalls. Accordingly, the IT organization should recheck the evolving architecture to identify any possible gaps, and appropriate corrective action should be taken.
SOA ensures that services are easily available to authorized users irrespective of their relationship to a particular architectural domain. Likewise, SOEA prescribes that all services, irrespective of their origin and state of evolution, should be traceable across the different domains of EA to ensure that business needs are met in a time-efficient way. An architecture such as this will allow end service consumers to easily access the desired functionality, information, and services on an as-and-when-needed basis. This is a critical requirement for organizations that need to transform their IT operations to quickly adapt to ever-changing market dynamics and business needs.
Saurabh Sharma, Senior Analyst, IT Solutions
Exploiting the Synergies Between Enterprise Architecture and SOA (November 2012)
Enterprise Architecture Strategy Report 2012 (October 2012)
All Rights Reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the publisher, Ovum (an Informa business).
The facts of this report are believed to be correct at the time of publication but cannot be guaranteed. Please note that the findings, conclusions, and recommendations that Ovum delivers will be based on information gathered in good faith from both primary and secondary sources, whose accuracy we are not always in a position to guarantee. As such Ovum can accept no liability whatever for actions taken based on any information that may subsequently prove to be incorrect.