<<Abstract: This article, the second in a
two-part series, examines why
strategic SOA investments so often suffer from poor technical
implementation and diminished ROI. In the first article [REF-1], we
established common SOA engineering misconceptions that are often the
root cause of poor SOA technical implementations. Within this second
part, we will examine key SOA engineering focal points and success
factors that are essential to successful SOA solution implementations.  As with the first article, the goal here is to empower IT leadership, management, and enterprise architects with the knowledge necessary to apply high-level guidance to SOA engineering teams and to position the SOA investment for successful technical implementation and maximum ROI. (Note: The information presented here reflects insights and knowledge derived directly from engineering teams designing and implementing large-scale SOA solutions within global IT environments. [REF-1]) Introduction SOA engineering perceptions are often shaped by vendor product and marketing literature and industry pundits reacting to new industry developments. The driving motivations behind much of this information are market forces and competitive struggles between market leaders. By their nature, these forums of discussion offer little focus on vendor-neutral, SOA engineering fundamentals and success factors that are essential to successful implementations. These engineering focal points are the topic of this article. Since we could fill volumes with SOA engineering issues and guidelines, we will scope the following discussion to a brief look at the primary focal points, along with some insights relative to these concerns. Each point is introduced and defined in terms of real-world engineering concerns, and includes a set of action items. Focal Point #1: "Delineate Service Infrastructure as a Distinct Subset of the Service Architecture" The term "service infrastructure" is somewhat subjective since different engineering teams might define its boundaries differently. Yet, it is critical to delineate this clearly because "service infrastructure" must address a separate and distinct problem domain with respect to the overall service architecture. Since vendor product stacks often blur the lines between architecture and infrastructure and often weakly address this distinct problem domain, it falls to the SOA architect to clearly identify these boundaries and ensure the associated problem domain is properly addressed. We have found it helpful to associate service infrastructure with those elements of service architecture that directly facilitate service producer and consumer interaction while ensuring the following: • scalable, high performance messaging • scalable, high performance XML and cryptographic processing • scalable, high performance, adaptive message and service endpoint security • efficient, high-performance execution of composite services • efficient "service mediation" services (virtualization, routing, transformation, SLA, etc) • high service availability • client abstraction and independence from SOA design and interaction complexity • consistency in cross-platform, client-service interaction • consistency in service exception behavior • efficient hooks for governance, auditing, metrics monitoring. Notice that virtually everything within this problem domain is focused upon or heavily impacts the client-side design-time and real-time service interaction experience. If service clients have problems with consuming services, the value of an SOA investment can decline dramatically. Delineating service infrastructure with a focus on service interaction helps ensure the associated problem domain is properly addressed. Action Items
Focal Point #2: "Keep Your Service Infrastructure Lean and Mean" As your SOA design unfolds, it pays to never forget that everything you place inline between a service and its consumers introduces some overhead and subsequently some performance degradation. Successful SOA implementations never lose sight of this fact and strike an intelligent and prudent balance between the need for "service mediation" capabilities and the constant requirement to ensure a quality service client experience. Action Items Examine your overall proposed SOA infrastructure and ask the following questions:
Focal Point #3: "Establish Core Service Producer Foundations" By nature, services will be developed and deployed on a wide variety of IT platforms based on the whims of developers and the priorities and interests of various IT fiefdoms. This natural scattering and proliferation of service hosting platforms throughout an IT enterprise is detrimental to good SOA engineering. There are significant architectural efficiencies to be gained from consolidating service development and deployment within a core set of integrated, scalable service hosting platforms supporting a wide range of services. These efficiencies can be realized in the following areas: • security architecture • governance infrastructure • composite service infrastructure • information source and B2B integration infrastructure • trust infrastructure • administration and operations infrastructure • network and datacenter infrastructure • development skills and environments Action Items
Focal Point #4: "Adopt a Holistic and Strategic Perspective of SOA Engineering" No aspect of a service architecture should ever be designed in isolation. A mature SOA must support a strategic vision that spans the IT enterprise and eventually interacts with most key IT assets. As such, a service-oriented solution is much more than the sum of its parts. Each solution element must be designed with a deep understanding of its interactions, integrations, performance impact, security impact, operational impact, and its role in supporting the overall strategic SOA vision. Additionally, SOA design decisions should always be prioritized favoring broad, long-term strategic goals over near-term, narrow concerns. Action Items
Focal Point #5: "Always Design for Operational Scalability" This is an area of SOA engineering that's frequently overlooked, yet it can have a huge impact on long-term ROI. Operational scalability is the ability of a service-oriented solution architecture to establish and maintain highly efficient and adaptive, cost effective day-to-day operations as the solution grows and scales with time. It is also represents the ability of the architecture itself to be efficiently re-factored to accommodate change and dynamic business requirements. For example, let's assume business drivers call for a security change requiring that two fields within a service response document be encrypted. Let's further assume the service is secured via WS-Security and has five active clients on five different platforms. This security change requires that all five platforms execute a WS-Security and XML Encryption-compliant decryption cycle on the two response document fields. In the absence of good operational design, this simple change might require the following: • Five different system administrators on five different platforms must be notified. • Five administrators must use five different platform security tools to comply with the new security change. • Possible disruption of production software on five different platforms must be resolved. • WS-Security compatibility issues on multiple client platforms may need to be resolved. • IT must invest in five different system administrators skilled in the nuances of WS-Security and WS-Policy. There is little of anything efficient, cost effective or adaptive about this scenario. Operational efficiency and scalability is a key SOA engineering success factor that must be designed into the overall, end-to-end solution from the very start. Action Items • Envision a scaled SOA architecture / infrastructure (2 to 3 year maturity model). • Apply business use cases to this model that demand a high degree of functional and operational agility. • Look at all details necessary to respond with agility to these use cases. • Identify areas of concern relative to SOA operational efficiency and address them within the proposed architecture. Focal Point #6: "Design for the Service Interaction Problem Domain" In our first article, we introduced the concept of the "Service Interaction Problem Domain," which encompasses all issues associated with heterogeneous client platforms, applications and development environments interacting with services. These include the following: • SOA performance engineering • user identity propagation • user credential availability and propagation • SAML incompatibilities • Kerberos integration • single sign-on • platform trust relationships • client-side WS-Policy enforcement • WS-Security incompatibilities • client service proxy limitations • client security complexity abstraction • federated identity support and overhead. • identity and authorization management (IAM) integration and overhead. • portal client integration Although these are some of the most difficult challenges in SOA engineering, they do not enjoy a high degree of support from the SOA vendor community. Attaining ROI begins with making services accessible, consistent, simple and responsive for heterogeneous client platforms and development environments. Successful SOA engineering requires accommodating these architectural challenges within all phases of service delivery. Action Items
Focal Point #7: "Define and Implement an End-to-End SOA Security Strategy" Perhaps nothing has the potential to make or break the success of a service-oriented solution quite like its security architecture. Although the intricacies of a security architecture engineering could fill volumes, there are a handful of considerations worth highlighting: Understand the Scope of the Problem SOA vendor security products sometimes leave the impression that SOA security is mostly a service-side problem. It's important to acknowledge that strategic SOA security engineering begins at the IT perimeter where single sign-on frameworks convert user IDs and credentials into platform-specific tokens (thereby impacting the ability of service client applications on those platforms to authenticate to a service security framework). Security concerns extend to portal frameworks where identity and credential mapping can impact service client authentication and further extend to IAM platforms that may govern user security contexts, federated identities, authentication tokens and more. They span client-service proxy objects and their ability and limitations in conforming to service policy requirements and also span through network infrastructure and service endpoints to the back-end systems they interact with, and so on. Understand the Performance Challenge It's important to understand that SOA security architecture elements inevitably degrade service performance. The only question is how much? It's crucial to design every facet of a security architecture from the ground up, with performance in mind. Design for Operational Efficiency and Scalability Never lose sight of the fact that service security is both a client and service-side issue. A security architecture must therefore efficiently address the security issues of both service producers and consumers and support efficient, agile re-factoring of security behavior for both clients and services as requirements change in support of business dynamics. Action Items Build and document an understanding of how and where the SOA security architecture integrates with and / or complements the following: • IT perimeter single sign-on solutions • identity and authorization management (IAM) infrastructure • service client platforms • portal infrastructure • network infrastructure • back-end information systems Develop and document an end-to-end security strategy that spans these IT assets, accommodates their unique concerns, and aligns with strategic IT and SOA business goals. Furthermore, design SOA security subsystems in support of this overall strategy. Focal Point #8: "Invest in Expertise and Experience" Nothing will impact the success of your SOA investment more than the people chosen to architect and implement the solution. Some of the areas of expertise necessary to drive a successful service-oriented solution architecture can be summarized as follows:
Action Items Balance the natural desire to cut costs on personnel with the realization that SOA engineering is a challenging strategic investment with long-term consequences. Focal Point #9: "Plan for Governance Infrastructure Integration Early On" SOA Governance is more than a set of policies, procedures and authorities. Governance monitoring and enforcement requires architectural support and often this support is treated as an afterthought (which is a mistake). The integration of governance infrastructure should be part of fundamental SOA engineering planning efforts at their earliest stages. Governance infrastructure has design-time and runtime components. Poor engineering on the design time component will impact service reusability, security, deployment, and operational efficiency, whereas poor runtime engineering impacts performance and the value of governance metrics. All of these issues end up impacting the attainable ROI of an SOA initiative. Action Items Governance infrastructure has a close relationship with SOA security architectures and often integrates with SOA security elements. Consider viewing governance infrastructure as an integral part of your SOA security architecture and design it into your foundational SOA security strategy. Conclusion It goes without saying that SOA engineering, as a subject matter, cannot be adequately addressed by a set articles or whitepapers. It is also self evident that SOA management must rely heavily on the expertise and experience of SOA architects to yield a successful technical implementation. However, the insights offered in these discussions can provide a valuable starting point for gauging the directions, and ultimately the technical success, of any SOA engineering solution.>> You can read this at: http://www.soamag.com/I19/0608-3.asp Gervas |
