The principles are high level principles. They do not deal with design or organizational issues but may allude to them. They are part of the manifesto because they act as a guide in how one should approach SERVICE ORIENTATION and how one should apply the principles of SERVICE ORIENTATION. Following these principles will help to ensure that whatever gets delivered provides the necessary short and long term business value to justify its existence.
“Respect the social and power structure of the organization.”
At an enterprise level SERVICE ORIENTATION and a SERVICE ORIENTED ARCHITECTURE provide a more open mechanism for accessing capabilities through their SERVICE CONTRACTS. It makes it easier to reuse existing SERVICES and create new ones in line with business needs. What is very important in looking at this from an enterprise perspective is who owns the SERVICE, who has the budget and how do we cost account for the use of a SERVICE. Respecting the social and power structures of an organization is critical in understanding the economic effect of a SERVICE, how it is used and how it can continue to be used over time. Aligning budgets for SERVICES and aligning the use of SERVICES to some cost accounting mechanism requires that budgets are aligned to the power structures and that the SERVICE is cost accounted for, based on the social and economic power structures within an organization. Getting this wrong can result in SERVICE degradation over time as more people use it and budgets for its subsequent maintenance and operational use fail to reflect it use and importance.
“Recognize that SERVICE ORIENTED ARCHITECTURE ultimately demands change on many levels.”
This is a corollary of the previous principle. Adopting SERVICE ORIENTATION and implementing and using a SERVICE ORIENTED ARCHITECTURE requires alignment through the organization. SERVICES are used, SERVICES change, and SERVICES are composed, all of this can happen across the entire organization. Use happens from all parts of the organization, request to change comes from all parts of the organization and composition of new SERVICES may happen anywhere in the organization and may use SERVICES from other parts of the organization. This is why SERVICE ORIENTED ARCHITECTURE demands change at many levels. The capabilities that SERVICES expose become un-siloed and that makes them enterprise assets and not just assets for one business unit. This democratization of capability requires change on all levels of an organization as users express future desires driven by changing needs and as the implementation of a SERVICE ORIENTED ARCHITECTURE makes flexibility easier to achieve.
“The scope of SERVICE ORIENTED ARCHITECTURE adoption can vary. Keep efforts manageable and within meaningful boundaries.”
This is a principle derived from the Evolutionary value statement. It is far better to aspire to the benefits of a SERVICE ORIENTED ARCHITECTURE but realize them incrementally. Typically one might start with the portalisation (portal-led SOA) of some business unit and SERVICE ENABLE along the way. The additional cost for SERVICE ENABLEMENT is mitigated by a standards based approach to the integration of the underlying capabilities with the needs of the portalisation. What we see in Cognizant is that this approach is complemented by additional concurrent but offset projects that then seek to further SERVICE ENABLE along the way as the portalisation efforts move to another business unit. Portalisation is not the only way to start. One might have specific needs to reuse components or applications simply to make available data and process from several application but to do so in a more flexible way. SERVICE ORIENTED ARCHITECTURE adoption starts by making it manageable within meaningful boundaries and so can be effectively measured in terms of the business value that it yields. Never forget Return on Investment, it pushes and pulls development.
“Products and standards alone will neither give you SERVICE ORIENTED ARCHITECTURE nor apply the SERVICE ORIENTATION paradigm for you.”
Products and standards do not apply SERVICE ORIENTATION to deliver a SERVICE ORIENTED ARCHITECTURE but they may help. It is people who wield them, making sure you have the right skills to get the most out of a SERVICE ORIENTATION approach and get the most out of a SERVICE ORIENTED ARCHITECTURE is a key aspect of any SERVICE ORIENTED ARCHITECTURE program regardless of how it is constructed or the boundaries in which it fits. In Cognizant we specialize in matching the right resources to achieve a positive outcome and the role of the Enterprise Architect becomes a key to ensuring that all of the moving parts of the Software Development Lifecyle (SDLC) work together.
“SERVICE ORIENTED ARCHITECTURE can be realized through a variety of technologies and standards.”
A SERVICE ORIENTED ARCHITECTURE does not have to rely on an ESB, WSDL, BPEL or any other standard or technology. The key aspects of SERVICE ORIENTATION and SERVICE ORIENTED ARCHITECTURE are the descriptions that we call SERVICE CONTRACTS and the decoupling of them from the implementation of their capabilities at both design and runtime. An instance of an SERVICE ORIENTED ARCHITECTURE may use asynchronous messaging and pass documents between SERVICES. An instance may use WSDL invocations with some form of remote procedure call. An instance may use BPEL and it may use business rules. In all cases the de-coupling should be self evident. A yard stick for an instance of a SERVICE ORIENTED ARCHITECTURE is to locate a SERVICE REPOSITORY, because without one, de-coupling invocation on a SERVICE CONTRACT from a SERVICE IMPLEMENTATION becomes impossible to achieve in any uniform way.
“Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.”
A bit of motherhood and apple pie but something that the can certainly catch you if you don’t do it. Establishing a uniform set of enterprise standards and policies can reduce the risk of mis-delivery of a solution. Where there are industry standards they often leverage XML as a means of encoding information and it is better to use them than not. It can cut down integration costs and reduce the time it takes to deliver an enterprise information model as well as the processes that manage that information. The enterprise standards should cover all aspects of governance and should support rapid change. The policies should guide security choices, transactions, and service levels. One key relationship between a SERVICE ORIENTED ARCHITECTURE and this principle is that many industry and de-facto standards are seeking to use the same SERVICE ORIENTED approach to describing the processes that underpin standards, this is true in International Standards Organization, the International Swaps and Derivatives Association, Healthcare Level 7 and many others. For those SERIVICES that are outward facing this may mean that the SERVICE CONTRACTS are already defined which can help reduce the cost of external connectivity and provide cross enterprise interoperability.
“Pursue uniformity on the outside while allowing diversity on the inside.”
This is a cry for SERVICE CONTRACTS and process uniformity on the boundaries of the enterprise and diversity as to how you achieve implementation on the inside. SERVICE CONTRACTS mandate a degree of uniformity. We can go further by publishing our external boundaries in terms of the SERVICE CONTRACTS we wish other to see and the ordering rules over those contracts that make up the processes that we wish to make visible. In so doing we ensure a higher degree of interoperability.
“Identify services through collaboration with business and technology stake-holders.”
From a technology platform perspective it is important to identify core TECHNOLOGY SERVICES. These will have the highest reuse rating and you can only do this by understanding the technical requirements from the technology stake-holders. Likewise the only way to gain reuse at the business level for BUSINESS SERVICES is to do it with the business stake-holders. The widest collaboration, across business units will yield the widest reuse, even if you have a single project, it is worth gathering requirements from a wider set of stockholders so that you can plan effective reuse and change management over time. Hence “Recognize that SERVICE ORIENTED ARCHITECTURE ultimately demands change on many levels” and “Identify services through collaboration with business and technology stake-holders” are complementary.
“Maximize SERVICE usage by considering the current and future scope of utilization.”
Wider collaboration for effective SERVICE IDENTIFICATION is part of the process of understanding the usage of both current and future SERVICES and their utilization. Don’t just look at the functional aspects because the scalability will be compromised as usage rises. Taking into account the scalability issues mitigates the risk of retrenchment and ultimately failure of large scale enterprise adoption.
“Verify that SERVICES satisfy business requirements and goals.”
This principle may well seem obvious, but it has profound consequences. One of the things that SERVICE ORIENTATION and SERVICE ORIENTED ARCHITECTURE instances provide is a clean separation of SERVICE CONTRACTS from SERVICE IMPLEMENTATION. It matters not if you use WSDL to do this or SOAML or Abstract BPEL, what is important is that before a SERVICE is constructed (implemented) we can, at worst, manually check that the collection of SERVICE CONTRACTS match the requirements that gave rise to them. If these requirements are themselves derived from higher level business requirements we can check the derivation. And if the higher level business requirements are derived from business goals we can check their alignment too.
When we do this manually, and most good SERVICE ORIENTED ARCHITECTURE practitioner do exactly this, we call it SERVICE ORIENTED ARCHITECTURE GOVERNANCE and it is part of Enterprise Architecture Governance. It is part of the enterprise alignment process that is done manually.
Given that SERVICE CONTRACTS can be properly described in a formal and structured way (i.e. WSDL , SOAML and Abstract BPEL) and given that we can encode the requirements that give rise to these SERVICE CONTRACTS, it would make a lot of sense to get computers to check the SERVICE REQUIREMENTS against SERVICE CONTRACTS and automatically show that the "SERVICES satisfy their business requirements". We are not suggesting at this point that we can do the "satisfiability" test through the different levels of requirements or indeed the business requirements against the business goals - although even this is possible. What we are suggesting is that the immediate requirements (SERVICE REQUIREMENTS) that give rise to the SERVICE CONTRACTS can be automatically checked to show that the SERVICES meet their SERVICE REQUIREMENTS.
This is what Testable Architecture is all about and the wider "satisfiability" is what Savara will deliver over time.
“Evolve services and their organization in response to real use.”
Accept that we live with imperfection but strive to attain it. Accept that things change. In this way we can focus on evolution to ensure that SERVICES meet their business requirements as those same requirements evolve over time. Equally we may choose to re-organize services for the same reasons. We may choose to uncouple a composite or to change it to reflect changes to real use. The best user interfaces are always tested by users and Apple have been very much the masters of getting it right. Doing the same for SERVICES from the top down, the middle out and the bottom up by evaluating their use in real situations will reveal improvements on design, improvements to requirements and manifest improvements with continual alignment to business requirements and goals.
“Separate the different aspects of a system that change at different rates.”
Engineering for change is not easy. It requires an understanding of what is needed today against what might be needed tomorrow. A key metric is how executive management and in turn their immediate management team steer the ship. What are the controls and the points of change that they need to do their job. Understanding industry influences and trends on an enterprise and understanding the vision provide a way of scoping what needs to be made flexible in the future. Understanding the mission and strategic goals provide a scoping of the changes needed in the near term. Having effective change management procedures in place and effective change request processes are imperative to continual improvement.
Another key aspect of rates of change is that processes change infrequently, but they do change, but the decision point, we might think of them as business rules, change far more frequently. Hence outboarding business rules and using a BUSINESS RULES SERVICE is an important architectural pattern which complements outboarding of processes through orchestration and workflow.
Don’t think that what you deliver will not change or is optimal. Let the users use and make suggestions. If you get flexibility engineered in from the start then the cost of suggested change will reduce and the ability of the enterprise to optimize how it does things increases.
“Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change.”
When we create COMPOSITE SERVICES, just like when we create views in a database, it is important to understand the SERVICES that they derive from. Without documenting and making these dependencies clear we potentially run into huge change management and governance problems. It should be standard best practice to publish the key dependencies both in terms of the services that may be used and the underlying technology dependencies too. Such dependencies should be documented and published as some form of attachment to services in the SERVICE REPOSITORY.
“At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.”
Good design coalesces concepts into some form of cohesion. This is true for any piece of software that is constructed. SERVICES are no different in this regard and at each level of abstraction be it a BUSINESS SERVICE, a TECHNICAL SERVICE or a DATA SERVICE the principle of cohesion applies. Organizing and making things manageable takes effort and discipline but the rewards are often greater use and reuse because the focus of the SERVICE becomes clear and the concepts coalesce to deliver appropriate functionality for the level of abstraction.
No comments:
Post a Comment