SOA , as an architectural style and a discipline of software engineering brings business and IT to the same table by providing a portfolio of business intended services/capabilities as the common terminology that he business requires and IT will design, implement and maintain. SOA is focused on establishing a center of operations for design around a portfolio of services, which equate to a set of business capabilities, that the business looks to deliver. Integration has become a strong focus for SOA as well. There are various types of services, integration and business services to name just two categories.
In the traditional Application Programming Interfaces or APIs were merely a library of interfaces that components can access and communicate with each other. In an evolved definition that is becoming more and more prevalent, the notion of a RESTful API that is exposed outside an organization, that may expose a set of services in the backend is being promoted more widely, especially with the proliferation of interest in HTTP-based simple interfaces that can mobile enable an enterprise's subset of back end functionality that it chooses to expose.
Cloud services are services that are exposed externally, and can be consumed by all, often implicitly assumed to be outside an organization's boundaries just as an API or more precisely, a RESTful API. Cloud services may span the gamut of Infrastructure as a service (IaaS) all the way to Software as a service (SaaS) which may expose very large grain applications or smaller levels of granularity akin to the RESTful APIs we discussed above.
More detail on this later.
Business process Management or BPM is about streamlining workflow and introducing efficiency into a process of a goal oriented business process.
A Smarter Process is a process that is augmented by decisions and business rules that are part of the activities within the process flow. An event will have triggered the process flow due to the monitoring of a situation or of bubbling up the analytics we are collecting to generate an event. Backend systems need to be accessed, invoked for a transaction or connected to for some outlandish reason such as updating a system of record. These summation of integrations, process flow, rules, events and analytics are collectively called a Smarter Process.
Architecture, software architecture specifically, used to be only defined in terms of components, connectors and constraints per Shaw and Garlan.
However, it is increasingly evident to those of us who implement architectures on a daily basis for clients and internally within our own companies
that architecture requires the addition of composition, context and containers to make it operational.
-- what are the structural building blocks of a solution, or a style of architecture, of the elements that can be combined to produce a larger structure
§Composition -- How to compose or what are the valid compositions of components
§Connectors -- The components need to connect with one another, whether statically (as in an Entity-relationship kind of relation) or dynamically, as in a composition in an SOA, where you may have orchestration or choreography.
§Constraints -- The constraints on the connectors and/or components that provide rules of engagement of what is permissible and what is not.
§Context -- the context of invocation of a component is critical to the designation of how that component will behave
§Containers -- the components must live in some runtime container that will provide uniform life-cycle management capabilities for them
The short answer is:
Cloud is an initial application of SOA to infrastructure
--its setup, configuration, monitoring , management , with the essential elements of metering and billing added to satisfy the goal of a charge model of e.g., pay-as-you-go
-- the specific requirements for XaaS: resource pooling and virtualization , elasticity and multi-tenancy, dynamic configuration and provisioning
Cloud paradigm leverages SOA to deliver a charge-based model for non-business specific services;
Several people have written articles on this relationship:
Business Agility is an often discussed as a key desirable attribute. One of the ways of achieving Business Agility is through the portfolio management of a set of business capabilities and services , rather than application portfolio management which tends to intertwine the services and higher order business capabilities into an application -- not a robust and flexible way of enabling business agility and optimization.
The main building blocks that provide a platform for business agility are outlined below. I have elaborated the last one more than the others in this post, and will elaborate further in future posts.
Laws governing eco-system as a whole (e.g., to disallow
financial market meltdown in the wake of blind rule based automated short
selling in e.g., financial markets)
The ecosystem includes policies, rules and laws governing
Business providers and Business Consumers, and Business Brokers.
environment, market, legislation and ecosystem within which the business is
operating and evolving, forcing to change and vary based on forces within the
Business Context. The Business Context is a Business State
within the Business Eco-system.
are many changes that are constantly occurring within the business context.
Only some are business significant or should be “bubbled up” or surfaced at an
executive and business level, especially when Business Sensors detect a certain
threshold above which apparently ordinary events become important enough and
achieve a tipping point beyond which the business sensors should indicate that
a potentially impactful variation has occurred.
Business State is the result of Business
(significant) Change that causes the parameters and qualifiers of efficiency,
effectiveness, agility and performance to change. A change of state implies
that Business Outcomes may indeed differ as we transition from one Business State to another. The Business State
is a snapshot in time of the key metrics and information related to the
Business Entities model and reflect the key business domain elements of the Business Eco-system that under Business State changes.
EA (Enterprise Architecture) practitioners are …exploring the links between desired business outcomes and
A tipping point is
reached when IT begins to understand that business executives are not primarily
looking for products and services but
rather looking for business outcomes including increased output, higher
quality, lower costs, increased revenue and increased market share.
To effect the transition to become more business-driven and engaged
with business leaders, we should focus EA efforts on business outcomes.
and mechanisms to monitor, track, help modulate and govern business change as
key performance indicators track the events and occurrences within the Business
Typically, the board and top executives of a company state
the vision and strategy for the company. It is critical for implementation of
business performance solution in the company that the senior business
leadership translates and decomposes the high level vision and strategy
statements of the executive leadership to operational and actionable goals
associating KPIs to the actionable sub-goals on the way.
To achieve such end-to-end monitoring, metrics and sensors
must be injected in both planning processes and delivery processes .
Essential to this process is the Business Sensors that
detect Business significant Events and pass them on to the Business Policies
and Rules that would respond to them.
From a planning perspective, enterprise governance needs to
ensure that the right changes are initiated for the right reasons at the right
time. The underlying premise driving towards business agility is that such
agility delivers superior business value. But what if haste to achieve agility
results in low quality? Or what if speed of change is unsustainable from a
business operational perspective, thereby leading to deteriorating efficiency?
These are just two examples of the fundamental challenge that doing the wrong
things in the wrong way very fast simply means ruining your own business very
fast. There are two fundamental premises for agile change to be valuable over time:
the right changes; delivering better business outcomes with the least
amount of resources and disruption.
business performance and integrity while executing change.
For agile change to be sustainable the enterprise needs to
carefully plan and maintain an appropriate balance between effectiveness and
efficiency. Change in the large is based on continuous business re-engineering
towards strategic objectives (effectiveness). Yet while on that strategic
journey an enterprise needs to apply change in the small to continuously adjust
and optimize the current state and ultimately maintain business integrity and
There are two levels of monitoring – there is the monitoring
of the acting on plans and there is the monitoring of operations.
From a delivery perspective, the set of solutions designed
and implemented to achieve the business goals should be designed for
monitoring. Monitoring of business results is a key to business performance. Monitoring
of business results enables sensing of business significant events. Ability to
act upon to respond to the business significant events resulting from the
business activity monitors is essential to improve the business performance in
order to meet the business goals.
Therefore, business goals, solutions adequately instrumented
for monitoring and alerts, monitoring of business results, sensing of business
significant events, responding to these business events to take corrective or
predictive actions are key for a business to be in a path of success and growth
that can be adjusted and tuned based on actual results of the business.
Based on our project experiences over the past years, we feel there are 6 key ingredients of success with SOA:
1. SOA 101 -- basic understanding of key SOA concepts e.g.,
2. SOA Maturity Assessment and Roadmap (using OSIMM ; Open Group Service Integration Maturity Model) that implements an
3. SOA Strategy, outlining the path and projects and initiatives to embark upon for sustained success with SOA enablement for business agility
4. SOA Method (SOMA) that provides the prescriptive guidance as to what to do within the software and business architecture life-cycles
and yet work in tandem with
5. SOA Governance to institutionalize the key processes needed to sustain success
6. Consideration of an SOA Reference Architecture now a industry standard,
I've participated in a lot of SOA projects around the world and very often I'm asked to answer questions about aspects of SOA. These are often recurrent questions that most of my clients and her colleagues are asking. So a colleague of mine, Kerrie Holley and I decided to consolidate these questions and answers into a book so that more people can access the questions, see if they are relevant to their particular circumstances and hopefully benefit from the responses.
I have started a separate blog at soaquestions.blogspot.com
to discuss further questions and comments specifically about the book .
Following the thread on Agile and Adaptive Business Performance and Optimization
Business Performance (BPer) is a measure of key performance indicators over a period of time. Within that period, we indicate there is BPer if the anticipated metrics and KPIs are exceeded by the actual KPIs.
For this to happen, Business Processes need to have been identified and engineered appropriately to achieve business goals measured by the KPIs.
The underlying Services that are orchestrated to produce the Business Processes should be selected or identified using a rationalized Service Identification method
(e.g., SOMA -- Service Oriented Modeling and Architecture) that encompasses the needs of various aspects of granularity, performance, agility, flexibility and complexity.
The Business Architecture should follow an agile and adaptive model to incorporate changes needed to accommodate sustained business performance and allow for continuous optimization.
Having an underlying Service Portfolio that allows the selection and combination of those services in nex contexts into Business Processes is one of the key factors in achieving and maintaining sustainable Business Performance.
I will discuss other factors in my next entries.
Greetings Dear Readers.
I would like to pose a question, to which I would like to invite your responses or further elaborations. Then we will discuss this in greater depth, as I begin to discuss my own views on this.
In your opinion how does a company achieve and maintain sustainable business performance?
What are the factors impeding the achievement of desired business performance?
As our industry continues to mature in the adoption of SOA and related technologies, we are witnessing not only the subsiding of hype but also, the emergence of new issues that are surfacing due to growing pains. These issues include the need to change service interfaces as they evolve in conjunction with changing business requirements. The service portfolio which is the single point of reference for an enterprise's business capabilities undergoes evolution with external and internal changes that are ongoing within and without the enterprise.
As the Service Portfolio, part of the Service Model, matures, changes to the service interface, and the service contracts are inevitable. I was approached with one solution: to put them under change control. However expedient this measure, it is not a cure, but temporary stabilizers of organizational turbulence. Changes to the underlying IT capabilities that reflect the business needs that are dealt with in a proactive manner tend to stabilize over time and yield the agility that helps power sustained business performance.
Properly designing the services, i.e., proper Service identification techniques and practices are paramount for alleviating these types of issues. Second best is to use a registry and repository to store and manage them centrally. And of course you need a source code control system to manage the code that is going to be using the services.
The use of correct Service identification for alleviating the risks and impact of Service Interface and Service Contract changes coupled with management and governance in a Service Registry and Repository are thus paramount.
Further, as services abound and the organization feels more comfortable in the creation of new or modified (see above) services, the need to manage and govern this Service Proliferation Syndrome becomes increasingly important. Again there are two aspects : one of which is doable at design time and another at runtime. Service Identification coupled with Service Refactoring and Rationalization (SRR) help mitigate the first aspect -- design time best-practices. Secondly, the monitoring of Services at runtime come hand in hand with the Service identification and Monitoring approach to alleviate Service Proliferation.
it is important to source IT constructs that directly support the business goals and processes. In order to do so we will explore the six fundamental constructs of service-oriented architecture. Elevation of the notion of the service or service interface and later on the service contract from a programming construct to the level of an architectural abstraction was a key paradigm shift in software engineering. By the service does not stand alone. It needs to be implemented using some component. The data has to be passed to the service to the component back to the databases and data warehouses and information systems in the backend, processing needs to be completed information retrieved and returned to the requester of the service. Thus information is paramount for services. As a service proceeds with its processing there are certain rules that apply. The invocation of the service should be a more intelligent invocation than that of the method on an object. Generally speaking it is common practice to invoke a method on an object without the necessary cards and without the necessary application of rules. It is typically left up to the application logic to implement those rules. With service-oriented architecture is important to although externalize the rules pertaining to a service but make the application of those rules visible to the service consumer or service requester. The service is also governed by a set of policies that allow the service to be changed without having to fundamentally change the implemented capability behind the service. Services should not only respond to a direct invocation but should be able to respond automatically in a subscriber will fashion to the triggering of that even
Thus it is critical to understand the six fundamental constructs of service-oriented architecture: services, processes, components, information, rules and policies and events. Services can be a comic or composite. As they participate as the steps of the business process, services can be invoked at each one of these steps allowing a shared set of common services to be utilized in a BPM context. therefore, processes are also one of the fundamental constructs of SOA.
Your architectural description should capture these six constructs as you meander through the journey of the software development lifecycle.
also, note that all of the six constructs are motivated by business level constructs. The following diagram establishes a relationship tween the business constructs and the corresponding SOA paradigm constructs.
A lot of market buzz is going on around BPM (business process management). This is a resurrection of one of the buzzwords of the earlier decade. However this time, it is BPM powered by SOA. Service-orientation is the underlying factor that will make a big difference in BPM. Rather than Business Process Management being solely about the management and optimization or re-engineering of business processes in traditional workflow contexts, with SOA, the activities the underlying orchestrated process (composite services) can be flexibly changed within a shorter duration, provided governance is fine with the change, and thus enable a greater degree of business agility.
Over the years as I have taught, designed and implemented software architecture the question I have been asked over and over again has been:
What is Architecture?
According to the Arsanjani view of Architecture :-), the Architecture of a system is the holistic view of the relative configuration of a set of static and dynamic elements that include what I call the 6C's :
Components -- what are the structural building blocks of a solution, or a style of architecture, of the elements that can be combined to produce a larger structure
Connectors -- The components need to connect with one another, whether statically (as in an Entity-relationship kind of relation) or dynamically, as in a composition in an SOA, where you may have orchestration or choreography.
Constraints -- The constraints on the connectors and/or components that provide rules of engagement of what is permissible and what is not.
Composition -- How to compose or what are the valid compositions of components
Context -- the context of invocation of a component is critical to the designation of how that component will behave
Containers -- the components must live in some runtime container that will provide uniform life-cycle management capabilities for them
Traditionally, the first three have been the main focus in universities and textbooks. But the latter three that I have added seem to be essential to a more complete depiction of the operational or actionable perspective on software architecture.
Let me know what you think.
To engage in an eco-system, you need to sense the environment, the eco-system. Business sensors gather business significant events and apply business policies to see what actions need to be taken as they sense a threat, an advantage, a change in the business climate, in the eco-system architecture.
Thus, to measure business performance and monitor business agility, you need what I am coining as "business sensors".
A Sidebar: A Conceptual Model of Service-orientation Actionable Concepts
In the context of a cloud formation, where is the "enterprise", per se? Of course it exists in the traditional sense. And so does enterprise architecture. But in the context of a cloud, which may span private, public and hybrid instances, where is the "enterprise" now?
Rather than a physical location, the enterprise now seems to be more nebulous and "logical" or "conceptual". It now can be seen to expand possibly, with the cloud, as the amorphous mass expands so does the virtual enterprise. This is where the enterprise merges with the eco-system and you see the emergence and need for addressing aspects of the eco-system that span physical and logical enterprises. As we needed enterprise architecture, for the cloud we need an eco-system architecture.
Eco-systems are more dynamic, opportunistic in some instances; some shorter and some longer enduring alliances between interested business parties. This not only affects the IT side, as it were, in a "bottom up" fashion, but also the business architecture; in a more "top down" manner.
The structure and function of a business is defined by its model of what goods and services it provides and consumes; who it needs to partner with at what point in its dynamic existence. This relates to policies that cut across and senses the eco-system for more appropriate alliances and takes competitive advantage of this new configuration. A business architecture in an eco-system architecture is then configured by rules and policies driven by competitive business goals, not statically defined.
The cloud provides a virtual rockbed for the reconfigurable enterprise that supports its dynamic business architecture to sense and respond, anticipate and adapt to the ebb and flow of trends in the eco-system. The eco-system architecture defines and configures these elements that include the traditional business architecture, multiple enterprise architecture plus a set of rules, policies, that define desirable (to be sought) and undesirable (to be avoided) configurations of the business and IT as they ride on top of the virtual infrastructure provided by the cloud.
This constitutes the eco-system architecture of the future.
As the eco-system of business evolves into a more opportunistic convergence of business partners into an eco-system of value, similar to the notion of a value chain, but a more loosely coupled exchange of goods and services, the need is increasingly being felt for an upfront design of an architecture structure to enable smooth and measurable business operations.
Eco-system architecture defines the foundation of interaction between a set of semi-autonomous business entities that interact with each other using a set of configurable policies that define the valid business interactions among potential and prospective participants, such as business partners: providers, consumers and brokers.
Eco-system architecture extends Enterprise Architecture in a similar way that EA extends the notion of solution architecture. EA is analogous to "city planning" whereas ECSA is analogous to planning how the economy of the whole nation is structured through a set of rules, policies, standards and structures .
Even though SOA has been around for years, the community at large did not have a clear declaration of intent and "values", although individually, there appeared to be a large degree of consensus. Formalizing this consensus, a group of seasoned SOA practitioners got together recently and agreed to a high level declaration of intent.
Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.
We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.
Through our work we have come to prioritize:
- Business value over technical strategy
- Strategic goals over project-specific benefits
- Intrinsic interoperability over custom integration
- Shared services over specific-purpose implementations
- Flexibility over optimization
- Evolutionary refinement over pursuit of initial perfection
That is, while we value the items on the right, we value the items on the left more.
SOA Manifesto Guiding Principles
We follow these principles:
- Respect the social and power structure of the organization.
- Recognize that SOA ultimately demands change on many levels.
- The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.
- Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you.
- SOA can be realized through a variety of technologies and standards.
- Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.
- Pursue uniformity on the outside while allowing diversity on the inside.
- Identify services through collaboration with business and technology stakeholders.
- Maximize service usage by considering the current and future scope of utilization.
- Verify that services satisfy business requirements and goals.
- Evolve services and their organization in response to real use.
- Separate the different aspects of a system that change at different rates.
- Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change.
- At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.
© 2009, the above authors, this declaration may be freely copied in any form, but only in its entirety through this notice.
We have just published the SOA Manifesto
. This document helps guide the values and principles of service-orientation and service-oriented architecture.
"Service orientation is a paradigm that frames what you do.
Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.
We have been applying service orientation to help organizations consistently deliver sustainable business
value, with increased agility and cost effectiveness, in line with changing business needs.
Through our work we have come to prioritize: "
A set of 6 values are then outlined, followed by a set of 14 principles that help guide the implementation of the values.
When faced with the forces outlines in the value statements, we provide a preference for one rather than the other, even
though both may be viable under certain circumstances.
I will post links to other authors of the manifesto soon.
The IBM Service-oriented Modeling and Architecture(TM) (SOMA) is IBM’s end to end software development and integration method (aka, process life-cycle) based on service-oriented software engineering principles to produce enterprise and individual project-level SOA or non-SOA solutions. This method includes prescriptive guidance applicable during the phases and iterations required in a software development process life-cycle. This guidance includes the activities and tasks to be performed by various designated roles within the life-cycle requiring input work products and producing or updating output work products and deliverables at specified junctures within the life-cycle. The tasks leverage a set of techniques (“capability patterns”) that prescribe and promote the use of best-practices included in the method, in conducting and accomplishing the task and to instantiate the related work products and deliverables.
SOA enables business agility. It enables flexibility of IT
systems that support the business architecture. As the business changes, the IT
systems required to support the business in a volatile environment of
competitive engagement, are less prone to change.
The history of software engineering started with the
separation of functionality or processing and data. The data of the processes
that manipulate the data were traditionally separate. There came a time when as
the pendulum swung emphasis was placed more on the data in one era ended and
the pendulum would swing and emphasis would be placed more on process.
Eventually object oriented programming, which evolved into object-oriented
design and object oriented analysis, played a key role in the unification of
process and data. David Parnas was the first to suggest the notion of
information hiding. The notion of information hiding was that access to
information or access to data was strictly done through the functionality
provided by an object. Those that object encapsulated its data and protected it
from direct manipulation. It offered a set of operations that you could perform
on the data, but you could only invoke those operations do not access the data
Objects often reflected real-world objects. The identity of
the real world object was used as an abstraction and implemented in a software
system as a software object. Identity often corresponded to a real-world entity
although helper objects evolve from the IT constructs necessary to implement
the real-world construct in a computer system.
One of the most important principles of object oriented
programming was based on a separation of concerns not only in the domain of
abstraction but also in terms of separation of interface from implementation.
Not only did we separate data from the operations that manipulated the data all
in one object, but we did so one step further by separating the interface of
the behavior from the actual implementation of that behavior. The behavior or
rather its implementation, actually change the state of the object or as it
were manipulated the data directly. However, there must be several ways in
which we can implement this data manipulation. Even though there may be several
ways in which we can implement this manipulation, there is typically one way to
represent the interface or the externally visible signature that would be used
by a consumer to request a change to be made to the data that the object owned.
This principle is called programming to interfaces rather
These interfaces coupled with the notion of composing a set
of similar objects that often had interdependencies among them into the next
level of encapsulation which was called the component lead to a whole new era
of -based development. It exported interface and could contain multiple objects
all of which would typically be expected to be related to one another in some
logically cohesive fashion. These objects were expected to be highly
collaborative with one another and thus made sense to be called located within
the packaging of a single component. This allowed not only manageable
functionality but also decrease the risk that nonfunctional requirements would be
The promise of object orientation
evolved into the
promise of building an industry around a set of reusable components that can be
marketed and shared across a wide variety of market segments. This marked the
beginning of the era of component-based development. With the passage of time
even though components and component libraries as well as new programming
languages that directly supported the component-based paradigm evolved,
component-based development did not make its way into the business world or
gain visibility as the bridge between business and IT. Thus, for the most part
the significant impact of component-based development remained within the realm
of IT and for the most part the impact on the business was negligible.
What is Cloud Computing? Similar to the Initial era in which SOA was trying to be defined, we are now in the era of more definitions. That is not in itself a negative thing, but a necessary part of the formation of new technology as they become mainstream.
Cloud computing is essentially an extension of SOA and service oriented computing. It provides concentrated infrastructure, platform and data center like capabilities offered at a set of services over the Internet. The cloud has several unique characteristics.
The cloud itself needs to be viewed from both a consumer and a provider perspective.
from the perspective of the consumer they are looking for a service-based delivery model over the web in which a highly reliable efficient self optimizing and feed your head up infrastructure capability are made available to them.
From a Provider perspective, the cloud involves two key aspects of self optimization and virtualization using a service-based delivery model.
The service-based delivery model can operate under one of the following kinds of services: platform as a service, software as a service an infrastructure as a service.
in order to connect the consumer with the provider, the provider must publish in some metadata standard information interchange format the quality of service that it can provide and the services that it can provide, so the service consumer can select among various provider of various services they provide and the various qualities of service that are offered for each type of service.
Could computing is fundamentally a service delivery model. It is instantiated by an architecture that provides the services and is consumed by a Service Consumer's own internal systems.
cloud computing is a
service delivery model
in which a virtualized set of
are offered by Cloud Service Providers with the choice of quality of service.
Service Consumers then have a choice
as to what provider to select
Further more, the model should support a seamless portable view of service such that services
from multiple providers can be choreographed by a consumer or broker without having to
know about the inner workings of the underlying cloud infrastructures.
What do you think?
Amidst the current economic downturn, and in the mist of the survival instinct that is perculating around the world, it is tough to sit back and observe trends.But one unmistakable trend is that countries are shifting from an industry-focused economy (e.g., manufacturing, see the collapse of manufacturing
toward a service economy. The impetus for this gradual change include globalization, technological change,and an overwhelming demand for (cheaper and cheaper) services. In observing this shift, it becomes increasingly clear that services and the service economy play an important role in today's and tomorrow's businesses. As a reflection of this trend, a realization or crystalization of the trend, service ecosystems have emerged: including GrandCentral, eBay, Google Base, Amazon.com, SalesForce.com, and SAP Business by Design to name a few. Such marketplaces enable trading products and also services between various legal entities and with consumers (sometimes referred to as the anonymous legal entity). One major challenge for service ecosystems is the fact that services are not products or goods. This has the potential to change the game.
SOA continues to evolve through economic downturns and bends in the road. SOA has evolved into a set of underlying principles, concepts, technologies, paradigm and patterns of designing and building software; all predicated on a set of loosely coupled services that collectively support an organization's business processes and goals.These services provides the enterprise with an adaptive or agile capability to morph and transform itself in the face of environmental change.
As we look at the SOA Maturity Model we have called SIMM (Service Integration Maturity Model), we see a clear evolution path:
1. Simple Services (level 4.0 to 4.9) from 2005 -20072. Composite Services (level 5.0 to 5.9) from 2007 - 2009
now we see a lot of interest in paradigms and technologies that are BASED on Service principles, namely
3. SIMM level 6, Virtualized Services, in the form of Software-as-a-service (Saas) and Cloud Computing.
Services have become Pervasive, they can be found in many of the recent initiatives including Mashups, BPM, Infrastructure, Enterprise Architecture, Governance, etc.
The notion of an SOA is finding new applications in new areas and continues to morph and integrate into new things, ingesting new use-cases but retaining the base principles of service-oriented computing.
In an effort to be responsive to a number of requests for an update to my old manuscript for "Principles of Advanced Software Engineering: Variation-oriented Analysis, Design and Implementation", let me give you folks some background on the subject. [Background]Originally, I wrote a manuscript back in 1999-2000 and used it to teach my classes of Graduate students in computer science for my advanced software engineering
class. Since then I and a number of my colleagues have written several articles on this subject and have extended it into various domains: Variation-oriented engineering, variation-oriented requirements analysis, VOAD for SOA Solutions
in addition to the base variation-oriented analysis and design. This topic also relates to my work on patterns for stability and symmetry in software architecture which I was writing for the pattern languages of programming conferences. I also did a blog entry on VOA that describes the high level basics of this paradigm.[More Current] VOAD is an integral part of the SOMA method
for building end to end enterprise and applications solutions based on SOA principles (whether or not you have a full SOA implementation in mind. VOAD intersects with another very important notion that I have been researching and applying on projects, namely, context-aware services (CAS). Manners externalize semantics for on-demand composition of context-aware services.
Manners define the context-aware behavior that is needed in order to externalize component manners to achieve greater maintainability
and reuse. This article shows how you apply VOAD in order externalize the changing aspects of the software, so you can decrease maintenance costs, enhance reuse and actually increase flexibility in design and implementation of your software solution. This is a rather popular article and has been cited in a number of other publications
. I think this is because we show the practical application of VOA to create a dynamically reconfigurable architectural style. Also, I believe this element is one of the characteristics that will be needed in more mature SOA Solutions. So as organization's adoption increases, they will need more mature ways of doing SOA, and VOAD is a key to achieving that.Empowering the business analyst for on demand computing
explores Grammar-oriented object design (GOOD) which is the way in which we apply VOAD for externalizing manners. This article describes a project we did in the public sector for harmonization of multiple redundant business processes across the world. This is immediately reminiscent of the value that VOA brings: one of which is to consolidate business processes and optimize them by eliminating redundancy.I suspect that is why I am getting these emails on putting more out there on VOAD and to update my older work to reflect the impact and opportunities for SOA. I get the message :-) and will do so.
A new article in the IBM systems journal is out on SOMA
that describes the method in a bit more detail than I did in 2004. This article describes a method that has now exercised hundreds of projects successfully and thousands trained worldwide in its delivery. This edition also features a number of articles on SOA.
Here is the abstract:
Service-oriented modeling and architecture (SOMA) has been used to conduct projects of varying scope in multiple industries worldwide for the past five years. We report on the usage and structure of the method used to effectively analyze, design, implement, and deploy service-oriented architecture (SOA) projects as part of a fractal model of software development. We also assert that the construct of a service and service modeling, although introduced by SOA, is a software engineering best practice for which an SOA method aids both SOA usage and adoption. In this paper we present the latest updates to this method and share some of the lessons learned. The SOMA method incorporates the key aspects of overall SOA solution design and delivery and is integrated with existing software development methods through a set of placeholders for key activity areas, forming what we call solution templates. We also present a fractal model of software development that can enable the SOMA method to evolve in an approach that goes beyond the iterative and incremental and instead leverages method components and patterns in a recursive, self-similar manner opportunistically at points of variability in the life cycle.
SOA is the next step in software engineering. The service-oriented paradigm comes to an increasing degree of maturity roughly 5 years after what I consider to be the start of serious corporate adoption.
We migrated from procedural computing to object-based and object-oriented computing. Then we moved to improve the state of objects with component-based software engineering. Now, we have evolved our best-practices as an industry and in academia and have moved into the era of service-oriented computing.
The gradual adoption and service maturity can be seen to move along a spectrum we have depicted in the Service Integration Maturity Model.Here we have seven levels of maturity across 7 dimensions from infrastructure to the business architecture.
The implication of this paradigm shift is that the best-practices of service orientation need to be integrated into the fabric of software engineering to be utilized on projects that (this is important, so you may want to mute the TV for a second) SOA may either not be part of it or a very small part of the project. Still, you would use SOA PRINCIPLES such as using the service model for a specification of the required functionality within a project or an enterprise.
What are your views on the use of SOA principles on non-SOA projects?[Read More
In the world of SOA, the economics of funding determines what services actually get funded to be developed. This is why we need a set of criteria by which we can assess which candidate services are a priority for inclusion in your next budget cycle. We call these criteria or gating factors, the Service Litmus Tests (SLTs). SLTs are included in SOMA , the de facto end to end SOA Development Method
Not all candidate services should be implemented as services; we may not have enough budget for that. But here this: we STILL need the functionality of the services that fail to pass the SLTs. Therefore those services still need to be implemented as part of some service component or realized by an application.
Economics is hand in glove with governance and of course SOA Gov includes the issues of economics, funding and budgets and ownership.
Lots of SOA projects later, I have finally gotten back to this blog.
I am seeing a large surge in SOA projects, each with greater maturity and more complex needs; but some of the basic remain the same. Often, projectsface unpredictable and complex human situations which may defy rigorous algorithms and require the soft art of consulting. Some are attempting to bridle this erratic and unpredictable aspect of human and group behavior. More of the SOA Projects later.
A recent post by the Univ of Arizona
talks about the development of a software that sifts through tons of data and "will use sophisticated computational methods based on game theory, co-evolution and genetic development models to find solutions that make sense in illogical times. Genetic algorithms analyze situations in an evolutionary context, where actions with the highest “fitness factor” (chance of achieving the greatest success) gravitate toward one another, produce offspring and eventually rise to the top."
This form of evolutionary, convergent behavioral computing promises to be used in more and more simulation situations.Typically, rule engines are cluncky (technical term) and finding relations between multiple rules is a tricky proposition.Patterns can help. For example, the Business Rule Pattern Language
I have documented starts with a lighteweight way of handling rules and moves into increasingly complex ways of handling rules within object oriented applications.
Follwing its use on three past projects, I have recently revised this pattern language to support SOA. I have gotten quite a bit of email requesting this and I am responding by saying that I will be publishing a draft soon.
As people stood in line sometimes a day before the big day, June 29, I was thinking of the partnership between Apple and AT&T. What about other Service providers who provide wireless services; could they not interoperate and have a device, which theoretically might be provider agnostic work with their phone was well? Of course economics, partnerships and politics are the key driving forces here...
So in the world of SOA, economics, partnerships and politics play a significant role as well. In the world of SOA, the economics of funding determines what services actually get funded to be developed. This is why we need a set of criteria by which we can assess which candidate services are a priority for inclusion in your next budget cycle. We call these criteria or gating factors, the Service Litmus Tests (SLTs). They are embedded in SOMA , the de facto end to end SOA Development Method.[Read More
We have recently elaborated on our version of the SOA Reference Architecture based on a large number of client projects.The details can be found at : SOA Reference Architecture
If you have comments or questions about the article, please feel free to attach them to this blog as comments.[Read More
SOA Solutions are most often hybrid solutions. Yes, they focus on a set of services; but they often do not soley rely on services for the realization of the functionality that needs to be in place for the business.
SOA solutions tend to rely on a combination of architectural styles and implementation and realization constructs to craft the underpinnings of an SOA solution. The SOMA method utilizes a combination of approaches to Service Identification. This includes 6 perspectives: top-down business process driven, business policy and rule-driven approaches, bottom up legacy integration, bottom-up legacy transformation (intrusive changes to rip out legacy modules and expose them via access points), information as a service typically used to consolidate multiple backend data stores and resolve inconsistencies in the access, rules and synchronization of the data stores and lastly the message-driven approach which seeks to integrate systems using a service interface.
Among the approaches above, although some are more established than others, information as a service affords a unique perspective in solving challenges relating to information. For example, data access interfaces and their underlying data access logic might need to be externalized judiciously if multiple channels are seeking to access and manipulate data from potentially multiple access points. The need for consolidation, synchronization and management of the data along with the need to have a coherent set of policies be applied to the data calls for the information service “entry point” to SOA.
Service-oriented modeling and architecture (SOMA) has become the industry de facto standard for SOA Methods. Introduced by IBM in Jan 2005, released recently as RUP/SOMA 2.4, it covers the identification, specification, realization and implementation of services, components, flows (processes), information and composition.
SOMA uses Information Analysis, Modeling and Planning during identification, an Information Specification during design and a number of artifacts during Realization and Implementation including considerations for Enterprise Information, Master Data Management, Conceptual, Logical and Physical Data Models.[Read More
[b]S[/b]ervice. Refers to how we use a service interface as a contract to decouple or loosely-couple a service provider from their prospective service consumers. Providers publish services, prefereably and increasingly in registries or service repositories (where they can be better governed). Consumers are looking for capabilities / functionality along with a set of non-functional requirements or service level agreements (SLA) that they want to be able to declaratively specify.
Services allow a business to expose its main operations to a well defined set of partners, clients and world at large, without giving direct access to its underlying IT systems, butthrough the surrogate of a web service.
The structure of an SOA, introduces services at an architectural level (a layer dedicated to services in the architecture).
In object-oriented programming we tried to separate interfaces from implementation. IN SOA, we have carried that programming practice up to the architectural level and now have a layer dedicated to enforce that programming best-practice at a design level.
[b]O[/b]riented. The orientation is not object-orientation or component-orientation, but rather, service-orientation. This orientation is a tendency towards using services above the other options; not to exclude those options. Thus, when we apply the service litmus tests to the portfolio of candidate services we will end up with a smaller set of services and a number of other capabilities that still need to be implemented using some technology: legacy, package or custom, even if it is not a web services implementation.
[b]A[/b]rchitecture. SOA is a style of architecture and relies on the sound principles of software architecture, including the fact that it is merely one style, to be combined with other styles to form hybrid solutions to handle complex projects and real-world situations. Booch talks about bringing the 'A' back into SOA. I would say that as we overcome the hype of the acronym, we turn our attention to each letter and take action on what it signifies; including the A part for Architecture.[Read More
[First a bit of history]. SOMA, IBM's SOA Method is now (officially) 2 years old. On Nov 9, 2004, I published a short paper describing IBM's SOA method: Service-Oriented Modeling and Architecture (SOMA)
. We had been working on extending current methods for SOA before that, and I have documented our efforts in a SOA redbook (chapter four)
which describes a primitive version of SOMA. Since then, a lot of work went into the method and SOMA took a quantum leap in 2004-2006 timeframe, as we formed teams around it and have successfully completed a very large number of projects in various industries and geographies and have taught about a thousand consultants and many clients to effectively use and deploy this method when designing SOA.Chances are that an SOA project will need to do a bit more than ad hoc web services implementation and need a bit of design. Some may even need some analysis of services components and flows, which are the fundamental elements of an SOA. Current methods do not have support for SOA and its fundamental constructs. This is where you can use SOMA, to identify, specify, design and realize the services, components and flows(processes) of your SOA. Based on a large number of project experiences over 2002-2004, we extended existing analysis and design methods, including global services method, which is an internal IBM proprietary method, as well as the rational unified process (RUP) and added the tasks and work products and roles necessary for the analysis and design and implementation of a service-oriented architecture (SOMA 2.x).
[Cut to present]. Yesterday, IBM announced a number of important tool updates. One of the accompanying plug-ins for the Rational Method Composer includes SOMA on top of the familiar industry method, RUP. Previously, SOMA was only available with IBM's internal Global Services (GS) Method. We have now extended this reach due to popular demand. This was a collaborative effort within IBM between Global Business Services (SOA and Web Services Center of Excellence's SOMA team) and Software Group's Rational division. Simon Johnston
and I have been working to deliver SOMA on top of RUP. Not all tasks in a method have to do with services and SOA; so the underlying method, like RUP, can take care of more mundane tasks like use-case modeling, etc.The end result of this work is the release of IBM RUP for Service-Oriented Modeling and Architecture V2.4
, which represents the combination of the Rational Unified Process (including RUP for SOA) and IBM's proprietary method, SOMA. This means that IBM has a single commercial method for the development of SOA solutions, whether you buy that method for your own use or you contract with IBM services; the customer gets the value of the combined experience of IBM's product and services communities.
SOMA is maturing based on new trends and new requirements; so you can expect to see further releases of RUP/SOMA in the future.
It is convenient to enforce the notion of scope in an SOA: "exposed services" only make sense when you define the scope and context in which they will be exposed. We refer to SOA as being fractal. This means that you can apply SOA and expose services in a fractal manner: you can define services for a project, a LOB, a few LOB's , an enterprise, an eco-system. For example, a Service Portfolio (part of the Service Model) will have an attribute of scope that helps define, for example, how each business unit has it's own set of services they use "internally" and also a set of services they expose "externally" to other LOBs and the rest of the enterprise. Each scope can be a Service Provider and a Service Consumer.
This addition of scope and role to the service model alleviates many issues in governance, boundaries, funding and indeed in the identification and specification of services in your SOA.[Read More
As the need for IT to absorb variations increases, with the demand for greater business flexibility,we are confronted with some basic questions: how do we design simple for today, to get the current job done, but not "box " ourselves in a corner so we can support the required flexibility ?I think one major answer to this problem is Variation-oriented Analysis and Design (VOAD). VOAD consists of three main types or axes of variation: structural (type|data), process and policy/rule variations. Structural variations are often based on the identification of Types: Customer Type has variations like Gold Customer, PLatinum Customer and Normal Customer. Often this relates to variations in the structure of the class, or of attributes and data associated with the entity (looking from both OO and Data views).Process variations are when you recognize that a Gold Customer may start from a common base, but branch out into a different set of activities for registration or loan processing, for example. Policy or Rule Variations relate to the Rules and Policies (Rules about rules) that apply for each Type of Customer, for example.Clearly these three aspects of VOAD are related and complementary. It is often useful, in practice to distinguish and treat these three axes of variation.Once you analyze the variations along each axis of variation, you come up with a set of variation points: things that will tend to change or remain less stable. Deal with each variation point by applying a pattern. For example if a variation point for calculation of interest is required for various types of Customers, then a Strategy Pattern would be used to handle / instantiate that variation point.Note that variations tend to occur across all layers of an SOA.
.Not all that changes is a variation that is warranted to capture and model: only those that are architecturally significant will be worth your while to consider. How do you tell? An architecturally significant variation is one in which impacts the architectural /design decisions you will make and have a trickle down effect that will influence subsequent decisions in how you will build your architecture (e.g., SOA). The "domino" that will alter the course of other decisions is a significant or relevant variation.ANother FAQ is why focus on variations? Variations are more difficult to handle than commonalities. Previous literature focused more on identification of commonality which IMO has less of an architectural ripple effect than understanding, isolating and externalizing variations.
What do you think?[Read More
After quite a lot time of blog-draught for me, travelling frenzy overtaking me, as I travel to my clients and to share best-practices on SOA with my colleagues around the world, I find that we are indeed reaching a new phase transition in SOA. Last year I saw many look for solutions that called for the first phase of service modeling, namely what I call Identification. The latter part of last year and this year has been more of the next phase: Specification (design of services components and flows). Now we are beginning to see more of Realization of SOA; including prototypes that are expanded and strengthened into gradually more robust and production systems that support service level agreements...[Read More
One of the interesting problems is not just whether to have governance, or more specifically, SOA governance, but how much of it's elements should be implemented over a period of the adoption of more advanced governance practices.
Clearly organizations are at different levels of maturity with regard to their need for, adoption of and implementation of SOA governance. Therefore, it becomes increasingly important to fit the degree of governance injected into the organition with the culture, priorities, implications of introducing control points and feedback; who takes care of the feedback and how it gets managed and fed back as actionable items into the system.
Using the Service Integration Maturity Model, we diagnose where an organization is with regard to six dimensions of maturity; one of which is the "organizational dimension" and includes governance. The target, desired state of maturity is analyzed and a roadmap to implement SOA governance for that targetstate of maturity is depicted. Think of a realse plan for software: it is more realistic to plan a set of releases than an all out implementation of all key features that the project is seeking to implement. It seems obvious in that context. So it is with SOA Governance.[Read More
The Modeling and Design of an SOA should follow a method like SOMA (Service-oriented Modeling and Architecture). The Realization of your SOA will typically involve a hybrid approach that will include your legacy systems, possibly some packaged applications you own or intend to add to your portfolio and some custom applications you will seek to construct as you move your IT services forward to greater support of flexible business needs.
One of the challenges in this road to realization of an SOA is to know how to conduct Service Realization. Realization has to do with making Realization decisions about how you will be implementing the services, using which components, packages or legacy. It consists of:
1. Mapping Components to a SOA reference architecture2. Allocating services to components, packages or legacy required to realize them3. Conducting Technical Feasibilty explorations which defines a set of architecturally significant proof-of-concepts4. Making Realization Decisions
The following are some tips for making Realization Decisions:
1. Recognize that the realization WILL be a hybrid
2. Make realization decisions about which services (and their operations) will map to 2.1 a given existing asset (legacy), 2.2 which part will need to be custom built 2.3 which part will map to a packaged application (ISV package)
3. Do a gap-analysis for each of these choices. Most often, the mapping will not be complete: your new requirements will need "just a bit more" functionality or the mapping "will not quite cover the required functionality", or the legacy system was not built to handle the non-functional requirements imposed on the system.
4. Now that you have done a gap-analysis and decide there is a gap, you need to make some additional realization decisions on HOW you intend to bridge that gap; both from a technology view and a business-functional view. Will you use a special middleware product or build it yourself (inside your organization)?
5. The next major decision can be quite daunting: if there is a gap there are at least two ways to bridge that gap: change the business to suit the software or package or, customize and add to the package or existing software to meet the business needs. The old way of doing this is how packaged application vendors such as SAP, Oracle (Siebel), JD Edwards, etc. (in whatever state of acquisition they are right now)have approached the problem for years: change your business to fit the package from a process perspective. Customize the package from a data perspective to meet the organization's actual information needs (which should be pretty close to the templates given by the package vendors, by the way)
The SOA proposition is to put the business in the driver's seat; and not have the package vendors force changes to the business. A package-driven business vs a business driven IT. This is where methods such as SOMA can help with making these decisions in a judicious way. But there are no hard and fast answers here: only IT strategy coordinated with business strategy through SOA Governance is the key.[Read More
The Architecture section of develoeprWorks has released another Insight and Outlook column entitled: What is IT governance, and why should you care? Here are my views.
I start by what I think IT governance consists of and how SOA governance relates to it. Then I describe what I have seen as the important aspects of governance that need to be taken into account. My observations are based on my interactions with clients and the issues they run into day-by-day. I think governance, specifically, SOA governance, is an "umbrella" that encompasses other assets and offerings such as SOA assessments, SOA Strategy and Planning , SOA Methods (such as SOMA)
, SOA Maturity
etc. It lends them the oversight and support based on a set of agreed-upon enterprise policies that will ensure quality of service within the soa life-cycle.Also, Michael Liebow, VP of SOA within IBM Global Services describes his views on the state of maturity of SOA in the industry in an interview with SearchWebServices.
Here is an excerpt relating to maturity, which is, in my opinion a governance issue. "SearchWebServices: Along those lines, how many companies have you run into that would earn a certificate of occupancy for their SOA?
Liebow: Here's the deal, we've done thousands of implementations and nobody I know of has the full house built. We offer to the industry a maturity model for service-oriented architecture and there are seven levels of maturity within that. The first level of maturity starts around siloed applications. The notion though is that you get alignment between the business and IT, so that you have a business architecture, the application architecture, the infrastructure, the whole alignment from top to bottom in your organization. Level two speaks to the notion of EAI and essentially proprietary integration. Level three talks to the really decade-old notion of SOA, which was around components. These were not the same types of components we're talking about today, but around CORBA, COM, whatever. They were still somewhat hampered because they were hard-wired, but this is not a new concept. People have been trying to do this for a long time.Level four is where we get to services integration. It's Web services-based. You're able to expose services to be connected. We call it SOI, for services-oriented integration. It's an approach to integration that's much more flexible. And we think that most organizations we work with are trying to get to level four. The majority of organizations today are somewhere between one and three. Level five gets you to composite applications.SearchWebServices: Is it a rarity to see a company at level five these days?
Liebow: You can see examples of level five and organizations that are starting to get there. They're real leaders in their industries. By no means would I say they have a full house, but they are pinpointing areas of the business where they want to build that capability. Yet the industry as a whole is just on the verge of touching this area. There are a number of startups that are providing aspects around this, but the major vendors don't really provide this.We think that the majority of the industry is just trying to get to level four. They are trying to articulate a vision around level five. Six and seven speak to a level of dynamic sense and response, automatic, autonomic systems that's a future state. No one's there to any significant degree."
A previous version of the SOA Reference Architecture, Solution View was discussed in the Architectural Template
section of Service-oriented Modeling and Architecture and in Bobby Wolf's recent posting on Composite Services
We have found it important to add a few layers and make a lot of refinements. The meta-model describes each layer, the architectural building blicks in each layer, patterns of interaction and architectural decisions needed in each layer.
These layers are:
1. Consumer layer - any consumer of a service would reside in this layer
2. Business process layer (choreography and composition)-- a process uses a set of loosely coupled services in a choreography or composite application
3. Services layers -- a layer of service descriptions and policies, implemented through
4. Service Components -- (e.g., EJB's or .NET components) who privide the actual realization of the service operation, or the service directly uses or exposes
5. Operational Systems and Data -- which include packaged applications like SAP, Siebel, PeopleSoft (Oracle), Legacy systems, and of course the data bases that support the applications.
cross cutting these functional layers are the operational layers that support and intersect the above:
6. Integration Layer -- if you need/have an ESB it's here
7. Quality of Service layer -- all, aspects of security, monitoring, management and all other quality of service aspects are implemented and ensure through this layer
8. Data Architecture, Business Intelligence and meta-data layer -- provides data models, star cshemas or meta-data relating to and supporting the SOA
9. Governance Layer -- includes the procedures, processes, registry , repository and run-time governance needed to servce as support for the entire life-cycle
If you are interested in the details, and the above jives with what you are looking for, let me know. Comments welcome.[Read More
The Fibonacci sequence is a mathematical progression that starts with 0 and 1 and then continues to add numbers to this sequence that are equal to the sum of the previous two numbers. Thus, the first seven numbers in the sequence are: 0-1-1-2-3-5-8. People have started writing poems
to this sequence since a blog posting on blogspot by a screenwriter/children's writer a couple of weeks ago. This is sort of a variation of the more restrictive haiku which usually consists of a pattern of 5, 7, and 5 morae, phonetic units (usually deemed to correspond to the syllables of a language). Poems often follow patterns, as a guiding element; loose standard or template.
In order to form and flourish, Service eco-systems also need to conform to patterns, to flourish with the implementation of their best-practices and with standards to provide them with general guidance, even if this is only to provide a means to extend or use only relevant parts of the standard in more realistic cirtcumstances. SOA Governance distributes policy for compliance with standards, inclduing acceptable extensions as well as templates ofr workproducts such as the Service Model, which includes the categorized Service Hierarchy among other elements.[Read More
Companies who want to collaborate and are in fact, business partners can do so in two ways: proprietary and standards-based.Standards-based is most flexible but covers a spectrum of industry standards such as ACORD for insurance to a standard XML Schema with pre-agreed tags. This is the spectrum of standards-based interaction. As we move from a few instances of collaboration and access to one another's business processes, the adoption of industry standards based on XML becomes more important: the rules of engagement are well-understood and have been well thought-out by a an industrty body or consortium. The downside of this is that often the industry standard is too broad and all-empassing making its use cumbersome and company's end up using only a fraction of the standard. Standardized message structures across Lines of Business within the enterpise and gradually across the eco-system become increasingly important.[Read More
I have picked one of the favorite topics that I have received most emails on; namely SOA Governance, and would like to expand it to the topic of SOA Governance for the Service Eco-system.
But let's start small: inside the organization. Within the organizational dimension, we have the need for governance and specifically SOA Governance.
To ensure that the SOA Life-cycle is carried out correctly, we need the support provided by SOA Governance.
SOA Governance is more like an umbrellla activity that 1)oversees the functioning of the SOA Life-cycle and 2)defines relevant, currently apropos policies, 3) inserts control points and 4) communicates these policies, the values expected at specific control points to 5) ensure compliance with those policies with artifacts produced by activities conducted within the life-cycle.
Governance is more declarative; management is executive. SOA Governance declares policies and activities it expects to see, and delegates to management to carry out these actions to ensure conformance to policies, or sometimes, more importantly, to determine why a given activity, project or artifact must obtain an exception and WHY IT SHOULD NOT CONFORM to the governance policies.
George Galambos and I gave a talk last week at the annual IBM Technical Leadership Exchange about a topic that we have been talking about for some time now: the service eco-system. If you want to build a service eco-system you may need to look at some patterns that help you build your service eco-system
As we move towards greater maturity
in the adoption of SOA,there are a number of key challenges that need to be overcome. I like to call them the Grand Challenges of SOA. The first 9 are:
1. Business Case for SOA
2. SOA Maturity and Roadmap: What do I do next?
3. Service-oriented Modeling and Architecture
4. Industry Specific SOA
5. Building composite applications
6. Monitoring and managing across the eco-system
7. Governing the SOA eco-system
8. Eco-system flexibility with declarative policies, service management and externalized functionality.
9. Service proliferation challenges quality of service
What do you think?
SOA Governance is about the governance of the three fundamental elements of SOA, namely, services, components and flows. So we are governing the process, the artifacts around services, components and flows. In the SOMA Method, the SOA Method used to model, analysis design services, components and flows, we identify, specify and realize these elements.
This relates to the monitoring of these elements throughout the life-cycle; putting in control and check points and policies around corrective action as we develop these.
Governance seeks to ensure adherence to/compliance with policy along the execution of a set of process steps that may start from the manual/human aspects of the life-cycle and continue onward into the runtime enviironment. It often accomplishes this goal by planning and instituting a set of check points or control points where process results are cross checked/validated with a set of standards (including permissible alternatives) as defined by policy.
SOA Governance sees to it that these elements are relevant to the organization (vitality), are being reviewed and validated by stakeholders and being communicated within the organization as the service model is being constructed within the life-cycle.
The governance of the service life-cycle is necessary to ensure that the needs of the business is supported by a set of flexibly re-composable IT services or components.
In order to do so, there needs to be policies, principles, checkpoints, reviews put into place from a process perspective; the execution of this is delegated to management Run-time governance of SOA on the other hand involves runtime monitoring of events and service execution to ensure compliance with the qualities of service declaratively defined by SOA policies.
Nasa has announced
that one of its satellites have spotted a truly wonderful phenomena leading to the conclusion that it may have found evidence of liquid water reservoirs that erupt in Yellowstone-like geysers on Saturn's moon Enceladus.
After a long dry spell of blogging due mostly to heavy engagement on customer projects, I mark my midnight ruminations with the blog update. Multiple SOA projects in several industries: electronics, telecom and insurance. Sometimes I feel like what the satellite may feel like! Constant travel to meet with customers, find and fix their problems strategic and tactical in their journey towards SOA.
Like Cassini, I also discover some strange and wonderful things on client projects: the key challenges encountered on SOA projects. One of these is reklated to the human factor and the great influence of that factor versus the technical aspects of software engineering: the dynamics of organizations, people, communications, reporting, expectation setting and managing as well as mentoring others.
I play two roles: Chief Architect on client projects and university professor. As part of my latter duties I feel a need to convey some of my experiences to the next generation of software engineers that I teach in the following courses: Advanced Software Engineering, Dynamics of Software Architecture and Service-Oriented Architecture at the graduate level.
As I discuss how to become a software architecture with the masters in computer science I teach at MUM, one thing strikes me as very insightful to pass on to the students: that technology is many times the easy part! It seems to be the softer human skills that the architect needs to acquire for maximum effectiveness on SOA projects.
Many ISV's have professed new architectures for supporting SOA. For example
, they are modeling typical business processes and exposing them as services.
Again, whether you are going down the SOA path by way of "engrain in company DNA", or "Natural Selection" or "Grand Design", you need to:
1. Integrate with legacy (operational systems layer), implies consolidation and multiple federated integration scenarios whihc would call for using best-practices in SOA design
2. Ensure your consumer or presentation layer is loosely coupled
3. Then you can leverage all the SOA design sandwiched in between those two extremes.
4. BUT now, with the advent of the service eco-system
, your company cannot maintain competative advantage unless is it at a maturity level that supports cross business partner interaction using, yes, you guessed right, services.
To create the eco-system, we need to understand what the business collaboration requirements of business partners are and what they are projected to be.
Often it's not only hard to obtain requirements, but also to get the business to say what they really want, in what order and by when; instead a general wand is waved(inbued with the most expensive peacock feather, as only those who hold purse strings can have).
But no matter what you gotta get those requirements translated into IT speak. The dW Architecture posed its second question: "How do I translate business needs into IT requirements?"
I think it's mostly a matter of empowering business analysts with the ability and means to express their requirements properly
and to help them do that, we need a teeny bit of rigor.
Increasingly, technology is helping make life easier in a large-scale, objective fashion albeit more focused in certain geographic regions. On the other hand, companis are also focusing on providing the consumer market with intensely subjective experiences which may indicate a trend of increased personal isolation: for example, a company has developed newwearable display for video iPods
(typically costing 3x the cost of a typical iPod). We are accessible through cellphones, on the go; now we are accessible to entertainment providers, on-the-go.
Services on-the-go, tend to be context dependent; my choice in music and TV programs may be different from that of someone ten years younger. This may also be contingent on the time-zone I currently reside, to be able to get certain programming, and on the time of day. All of these point to a class of services, I have been referring to as context-aware services. An extreme version of this is when your cellphone announces to you that you are within walking distance of your favorite Chinese restaurant chain and it is near lunchtime in the current time zone.
Context-aware Services (CAS) is a convergence of a number technologies and paradigms: SOA, telecom, banking and personalization, to name a few. In some cases, context-aware services relate to the specific domain in which we are functioning: e.g., financial markets vs consumer banking vs insurance, etc.
This is what we will gradually see emerging on the horizon this year as the New Year dawns. Happy New Year!
One of the important aspects of SOA Governance that we have been discussion is that of Service Domains: rather than having a lines of business own systems, Service Domain Owners choose Service Domains which group a set of related services. These affinity of these services are often of a business nature, or originating from a buisness perspective at the very least.
Decomposing a business domain into its sub-domains and functional areas enables a set of natural boundaries that can be a good starting point for Service Domains.
The Service-oriented Modeling Approach uses this strategy to identify domains, decompose them and then put governance around them.
Every domain owner will provide a set of services and wil in turn, itself require a set of services for consumption.
Thus the publication of the servcie descriptions of both these sets of services are critical to get the service eco-system going in your enterprise.
This allows the Domain Owners to make decisions about implementation changes to Service Implementations without changing the Servcie Description, if the change does not affect the SLA (service level agreement) and QoS (quality of service).
A set of base services can be instilled into an organization as the primary business functions it provides and decide which ones it in turn requires from its business partners. (the DNA approach we discussed earlier
, recognizing the fact that there are three approaches
to this paradigm, each of which may fit your enterprise.
Instill, let go and observe the evolution of services as they are adopted at various levels of maturity (or not), exercise governance for communication of the services, obtaining feedback to ensure they are relevant and to check for compliance.[Read More
Back to the discussion of Service Domains: changes and ownership through governance.
Two readers have responded with interesting considerations.
MMahesh, your response brings about an important element of SOA: that of the separation of description from implementation and to IoD's point, if the change in question is only one of functionality and not SLA change or QoS change, then the Domain Owner has less of a say in this.
It thus appears that the service consumer expects a certain function (Service description) and a certain QoS. If these are satisfied, then the consumer if typiclaly happy.
Thus the change might not even affect the consumer, in which case the question is whether non-consumer affecting changes should be reported.
In some cases, I would like to point out that this may be warranted: where there is a deviance from a reference architecture, and i.e., of compliance. Now if the change makes sense then it must be propagated through the governance process of vitality which ensures continued relevance of the compliance criteria (eg a reference architecture or reference model) .
1. provider and consumer roles have their own concerns and governance applies to each individually and then to both to maintain a healthy service eco-system.
2. Change the implementation if you want (provider) or change it if you have to (consumer) and you are not getting your QoS or functionality. This ability to have the power to choose from various providers who suit your needs (functioanl and operational (QoS)), is a key feature of SOA.
3. Service Domains define a sphere of responsiblity, both functionally, operationally and financially.[Read More
Now you have convinced people to invest in building services for flexibility, redundancy elimination and business/IT alignment. Great.
Each business line goes about their way to achieve it, but soon will find out that there is one conspicuous issue: who is the Service Owner? If I build this service and it is used in multiple places, who pays for the changes if the changes are those I do not specifically "care about" in my line of business?
Thus appears the notion of Service Domains, where a domain defines a set of related services that some "one" can own, maintain, support and (obtain) fund (ing).
To make a chance to a service, contact the Service Domain Owner.
Here is a question for you:If I don't need to change the service description, can I change the service implementation? If so, do I still have to go to the service domain owner?
Several folks have raised important points in this connection. Namely (assuming I have interpreted the comments correctly):
1. A question of SOA Governance
"Do services come from some apriori (generalized, enterprise-wide or industry-wide) schema (Kant), or do they come from the specific local requirements (Hume)?"
2. Instill SOA into company DNA
: "The DNA or "Nature" has to be "Nurtured" in an Information Technology (IT) still in its infancy. You could think of the IT DNA as the defined lower metrics required for any IT shop to deliver Information. The key performance criteria for Information delivery SOA as a roadmap to bridge the communications gap between the "IT think" people and the "Business driver think" people."
3. Natural Selection
: The more we put in the DNA, the more restrictive the future generation of SOA will be, the less we put in the DNA the more fragile our SOA generation will be.
4. The Grand Design approach
: "...grand design, and hints at a roadmap created by an external, pervasive entity ... the lingua franca for cross-platform coding...."
To me, project motivation comes from two very diametrically opposed sources: pragmatics of funding (business drivers) and the passion of professionals (to do "the right thing").
In some organizational cultures, we will have an entry level of maturity that is going to be project focused and natural selection may indeed rule.
At the other end of the spectrum we have neterprise wide transformation efforts that are occuring with some degree of SOA governance that follows a roadmap, "grand design". This allows the "instilling of SOA into Company DNA" in a spiral form : not necessarily top-down, not project by project, but by whichever comes first. The governance in place sees to it that where the passion of professionals or the pragmatics of funding are the drivers, that success is achieved within the designated , I repeat, designated scope.
As diverse projects weave their way to SOA, SOA governance sees to it that Variation-oriented Analysis is conducted across projects by the enterprise architecture board (with business and IT representation), Service Refactoring is done to factor out common services that eliminate redundancy (the third Service Litmus test).
Immanuel Kant, grandiose philosopher, maintained that we have "synthetic notions a priori"; notions prior to experience that are embedded, as we would perhaps say today, in our DNA. David Hume, the empiricist, on the other hand maintained that our mind is a "tabula rasa" -- a clean slate that experience writes upon and we have no notions prior to experiences.
Should SOA start to be embedded in the DNA of the Enterprise or is it something that should be left as best addressed piecemeal, project by project, on an "as need" basis?
What do you think?[Read More
Adoption of SOA is a gradual process. While some organizations are dabbling into Web Services wrappering of applications as a means of exploring the world of SOA and deciding how to proceed, others are engaging in enterprise wide business transformation. Others are in between, and have defined their roadmaps, vision, strategy and criteria for assessment and governance. They are embarking on this journey by integrating application using Service-orientation. This latter is called service-oriented integration (SOI). This is the intermediate stage in which a lot of projects find themselves.
I have described this process and some patterns for embarking on this transformation to SOA using SOI
Inside IBM, we have been developing and leveraging a Maturity Model and Process for SOA called the Service Integration Maturity Model (SIMM). This is designed to achieve desirable stages of maturity.
We have found it convenient to define seven levels of maturity that are defined by the level of de-coupling and flexiblity achievable at that stage of maturity:
1. Silo (data integration)
2. Integrated (application integration)
3. Componentized (functional integration)
4. Simple Services (process integration)
5. Composite Services (supply-chain integration)
6. Virtualized Services ( virtual infrastructure and integration through virtualization)
7. Dynamically Reconfigurable Services (eco-system integration)
Each have a detailed set of characteristics and criteria for assessment.
Here is an informal description of the highlights.Level One
. Organization start from proprietary and quite ad-hoc integration rendering their architecture brittle in the face of change. Level Two
. Organizations have moved towards some form of EAI (Enterprise Application Integration), albeit with proprietary connections and integration points. The approaches used have been to look at legacy systems and attempt to dissect and refactor through data integration.Level Three
. At this level, companies have componentized and modularized major or critical parts of their application portfolio. They have used legacy transformation and renovation methods to refactor legacy, expose functionality in a more modular fashion, built J2EE, or .NET based systems with clear component boundaries and scope.
The integration between components, is through their interfaces and the contracts between them.Level Four
. The company has embarked into the early phases of SOA by defining and exposing services for comsumption internally or externally for business partners; not quite on a large scale but acts as a Service provider none-the-less.Level Five
. Now the company has extended it's influence into the value chain and into the service eco-system. Services form a contract between suppliers, consumers and brokers that can build their own eco-system for on-demand interaction.Level Six
The company has now created a virtualized infrastructure to run applications. This is another level of decoupling achieved after the decoupled of the application, its servcies, components and flows. Now the infrastruture can be tuned and made agile through the notions of the grid and the grid service. Monitoring, management and events (e.g., common event infrastructure) have been externalized.Level Seven
This is a dynamically re-configurable software architecture. Services can be composed at run-time using externalized policy descriptions, externalized management and monitoring.
A simplified version of this has been discussed in 2003 in the Introduction I gave as guest editor of the Communications of the ACM on Enterprise Components and Services. Also, the four simplified levels
have been discussed elsewhere as four adoption levels taken from SIMM
Mappings to CMMI
have also been done and are a natural way to try and understand maturity. The main challenge in a few of these efforts has been to be more than just a categorization according to some semblence of CMMI, and to justify why something is Defined, Repeatable or Optimizing, for example. This is often easy to do, due to the open and interpretable nature of the descriptions of each maturity level of CMMI.
The mapping to SIMM to CMMI is also quite straightforward; but the perceived value of this mapping seems distant other than the bandwagon factor of the success of CMMI. Service maturity relates to integration capabilities at various levels of business, methods, applications architecture and infrastructure.
CMMI deals with six levels of capability:
4. Quantitatively Managed
Each capability level
consists of related specific and generic practices for a process area that can improve the organization processes associated with that process area.Forrester
has been discussing various notions of maturity, although from a different perspective.
Zapthink and Other analysts have discussed SOA roadmaps, which can be facilitated using SIMM.
Elements affecting maturity include coupling, standards usage, service identification that supports business needs, business models, goals and metrics that need to be supported by services, technologies, governance, infrastructure, tooling, skills and deployment capabilities. Here
is a developerworks article that provides more elaboration on this topic.
Of course with the current hype around Web services and SOA, there are a number of events hovering around this topic.
IBM is holding a series of SOA Days
. The main SOA page for IBM products and trends can be found here
Another event is the 2nd SOA and Web Services Best-practices
conference in Chicago, and another is a workshop we are holding around the same topic at OOPSLA
2005, for the third year.
One of the main attractions of these and similar events are the battle stories we can exchange around SOA, which in the final analysis makes all the difference: what works in practice is the more important aspect of software engineering for clients.[Read More
Summer vacation is over for most families with children. School has either started or is imminently going to... vacations are therefore usually over and we are back into the swing of things. We were talking about building the layers of an SOA, based on an SOA reference model
. Let's discuss how to build the service component layer which is responsible for realizing the functionality and quality (adherence to non-functional requirements) of the service.
OK. So we assume know how to model and design an SOA. For that, we use some sort of Service-oriented Modeling method such as SOMA
You have gone through Identification, Specification and Realization of Services, Service Components and Flows (processes).
During Realization you need to build the SOA. You need to map each service, service component and flow to a realization decision.
Once you have this table, you then have an idea of what you will:
3. Integrate (wrap, adapt)
4. Subscribe to (if event driven or publish and subscribe)
5. Transform (break apart a legacy system to get access to hitherto hidden nuggest of functionality not exposed in the orginal application)
Let's take number 1. Build. Building something is often about using a programming model to construct that piece of software.
In the 6th installation of the SOA Programming Model, Ferguson, Stockton and Nally
talk about "A language-neutral, component-based programming model for service-oriented architecture (SOA) facilitates the implementation of Web services and their assembly into solutions."
This describes how to build the service components that will implement or realize your services.
The previous set of articles in that series can be found here
There is some excitement with this rich client-side engine that mediates data interchange rather unobtrusively in a browser frame, catching input and sending it to the server, catching the results and more gracefully rendering the results. This is a step up from the staccato jerks of normal HTML page interaction, providing a smoother transition between almost unobtrusive loads. Google's Maps
or Google Suggest
(see how the search narrows as you type) are examples of using this technology. You program
this with things like ECMA Script
Ajax is a composition of standards and technologies that includes:
* data interchange using (surprise!) XML
* data manipulation with good old XSLT
* asynchronous data retrieval using XMLHttpRequest
* standards-based presentation (XHTML and CSS)
* dynamic rendering and interaction using a tree structure similar to a Document Object Model
Adding this layer of mediation to the presentation layer of your SOA will further enable Web services consumption:
A lot of times I am asked to describe and then implement an SOA as part of a client project.
One of the recurrent themes I have seen is that SOA can be described quite succinctly in terms of three dimensions:
functionality, policy and composition.
Functionality has to do with the fulfillment of requirements on the business side.
Policy has to do with the quality of service, non-functional aspects such as security, behavior in the face of changing levels of availability and duress that the SOA is put under.
Composition is in terms of how to combine the three key elements of SOA, namely, services, components and flows into more coarser-grained entities.
National tennis associations tend to be run by local groups within communities that observe certain rules in their tournaments and are therefore sanctioned by the national tennis association. No matter how small you are, you can run a tournament if you can solicit enough participation from members and show a well-organized venue.
This lowers the barrier of entry and provides smaller cities the opportunity to stage tournaments and encourage skill in sports near a person;s hometown.
This network of sports communities are observing a common policy defined by a larger organization and implemented locally.
Similarly, as your company matures in its adoption and usage of SOA, and turns from small projects to larger and more intricate uses of SOA as depicted by the Service Integration Maturity Model (SIMM)
, the need to provide servies to business partners in a value net and to leverage services provided by other partners in the same value net presents a unique opportunity and a set of challanges.
The interactions between parties are no longer one offs but rather collaborative goal-oriented interaction in whcih a participant alternatively assumes the role of provider, consumer or broker and enacts business transactions that run across not one company but several companies transparently.
The leveraging of the capabilities of other companies within thi service eco-system enables greater value than static partnerships or of relying solely on ones own resources.
Furthermore, participants in the SOA Eco-system can be small or larger companies and the smaller ones can be shielded from unnecessary judgements so lang as they maintain SLA's and provide the advertised functionality. This is a network effect that the Internet saw in its inception, but of a new caliber for businesses to leverage one another transparent to their customers. Great empowerment.
I have been a strong advocate of the notion of service eco-systems and have been sharing patterns that help accomplish this task through the design of SOA and SOI
that is conductive to the creation and maintenance of a stable service eco-system.
Others have been talking aout various aspects of a service eco-system as well. For example, The role of contracts in the service ecosystem
. Some talk about the Web Services Eco-system and how we need tools
for consumpiton, test, creation and management.
Recently, George Galambos of IBM delivered a keynote on the Service Eco-system at the IEEE Int'l Conference
on Web Services 2005.
Aside from wildlife foundations, Economists also have found interest in ecosystems. For example, they discuss the valuation of an ecosystem
We'll be hearing much more about this important concept as technologies and organizations mature in their usage and adoption of SOA
I have recently published an article here on dW regarding SOA and SOI patterns
. Others have written in this space, most notably, Rachel Reinitz and Kyle Brown
, and Bobby Wolf, three of my colleagues.
I focus on the ways in which we have done SOA with clients and discuss things that we see recurring, that seem to work well.
Well, over this weekend, deep in space, NASA has succeeded with Deep Impact
and another impactor in the form of tennis balls were colliding: Federer has won his third Wimbledon
in magnificent straight sets. As Roddick, his opponent, said,(paraphrase) "he is getting better than ever which is a surprise. I have been training hard and he is still getting better. maybe next time I'll punch him...."
The NASA mission showed our increasing precision through technology manipulated through software and (hardware)machines (many times context-aware services and components, but that is another story...) and the tennis champs showed they can progress with even greater precision on the human side.
Our precision in SOA and our success in winning with SOA depends not only on the initial standards and enabling technology, but on extending it to the enterprise scale and beyond into the ecosystem of partners.
To do this, we must focus on externalization of policy, of context and of sense and respond to events; whether the impact of a man-made satellite the size of a coffee table at 23,000 mph onto a raging bull of a comet, or Federer serving and acing at a precise 125 mph. These events, if signifcant to their corresponding businesses must be sensed and responded to. The response cannot be blind: a set of rules must be selected based on the context in which the event occurred and policies need to consulted in order to determine the valid/optimal course of action suitable for the business.
SOA seeks to externalize the interfaces to functionality, so a service consumer can find or use the URL/I and bind to the function without having to worry about the details of the underlying implementation; its design or technology. The service provider needs to also externalize policy information. Both provider and consumer need to monitor services and this is typically done via events. Events can serve as a service invocation mechanisms to wake up a service in a sense and respond scenario. And as the services are merrily firing on their own in blissful automation, the monitoring layering of an SOA should check for certian types of events that it is listening for based on business priority and policy.[Read More
I have been talking about the notion of a service eco-system for some time now. This is a mutually beneficial digital/human enviornment where actors are businesses that can choose to link to a remote resource using Web services. They combine their efforts in a value-net of services; similar to a supply chain, but not just for suppliers and consumers; but for companies who choose to increase their competative edge by joing forces with business services porvided by other participants in the service eco-system.
You need an SOA method
to identify services that SHOULD be exposed to your eco-system.
Also there are various layers in your SOA. We call them a SOA Reference Architecure
. One of these layers is the data or information management layer. Check out this recent article on aspects of information management for SOA
One unique feature of SOA is that it is "fractal." The fractal nature of SOA implies that it is applicable in small projects, to one line of business, several lines of business sharing common services with slight variations, cross enterprise scope, between business partners in a value net and then on a larger scale in the service eco-system.
Granularity is a tricky topic that I get queried about very often. It's more than a single metric measurement; it's how useful the interface is to you the potential consumer and how you can re-compose it in your own application context.
But there are many consumers out there; at one end of the spectrum are low level API's such as those typically found in packaged applications that vendors expose as Web Services. Then we get the grand bundling of an entire application as a service at the other end of the spectrum.
But it's all about how IT fits the business goals. Allow me to digress. In karate, there is a notion of "maai". It is the distance you have to step back to avoid being punched when the attacker comes in for a punch and the distance you have to step forward in order to be able to strike. 'So, how long is a "maai"?' someone may ask. I don't know how many feet and yes, it depends on ....
Back to SOA. When we do goal-service modeling, the composition of services and their granularity is attached to the sub-goal in the goal tree that you create. Higher level goals requiring services will have larger granularity services.
Granularity is inspired by buisness usage context that maps to business goals fulfillment that translates into what services you need to fulfill a given goal.
Okay, now, we will practice that move one more time. Yoi...(ready)...[Read More
Of the six approaches to SOA, I briefly described the first one: top-down business driven. I am now thinking of how pilots are given various angles and approaches to airports based on traffic, wind, direction they are coming etc., which only shows that I need to get a life and travel less... but that's beside the point.
The others include: bottom-up legacy integration/enablement, data access driven, message or event driven , model-driven architecture (tools to generate web services) and legacy transformation.
Legacy Integration and Transformation are fundamentally bottom-up approaches: you start with something concrete and find a way to leverage it. Sorta like mathematical induction: from the particular to the general. Now back down to the ground of reality....
Customers want to expose functionality. In the first case functionality that is isolated and can be wrapped and mapped to a mid-tier application server. In the second case, the bottom-up approach is still related to legacy, but in this case the functionality requires some software archeology: it's embedded into the bowels of the legacy system. Now you need some form of compiler-based technologies (many of which evolved from the Y2K days) to extract re-usable portions of code that can be accessed from anywhere, not necessary through the mechanisms of the legacy system.
The two top down approaches are business driven and model-driven: the first one is based on bsuiness processes and the need to align and improve them. The second is based on tools and their ability to generate useful code from a top-down rendition of the business model or analysis model.
Some companies want to start with improving their businesses by focusing on the processes. Others may have more IT focus where they want to improve the business by improving the way IT does the job of supporting the existing processes.
Then we have two approaches that come in sideways: data access and message/event driven. Some people could care less about SOA or any other latest cool technology or promising paradigm; they just want to have a single uniform and consistent way to provide interface-based access to their underlying data: check the status of an order, place an order, access customer data, etc.
And others, coming in from the other sideways angle only care about integration; without knowing or caring about the two points of integration. In otherwords, I want to connect two systems they say and SOA gives me a very clean way to do so. I care only about messages exchanged between systems and the events that trigger the exchange of data or the invocation of a service.
When hitching a ride in the journey to SOA, there are at least six approaches you can take. One is a top-down business driven approach where you or your client want to improve and support business processes with recomposable services that can be exposed within the organization across business lines or between partners in the Service Eco-System
The migration path to SOA will require a choice of the approach.
IBM has recently acquired an open source application server from Gluecode in California. Here are the details of the Gluecode acquisition
I have been travelling every week for the past four weeks several locations per week... one theme seems to recur: the need to discuss what are the essential elements or constructs of an SOA, so we can go about building them.
In the world of OO, an Object has identity, state (attributes) and behavior (methods). In the world of SOA, a Service has a description which describes the interface to use to invoke its functionality. To be successful, services must also have a contract showing their quality of service (QoS) attributes. Thus, a Service Provider would guarantee a certain quality of service accompanying the functionality it is providing.
In order to build an SOA, which often implies both consuming and providing services, we need to identify three contructs: services, components and flows (processes)
. The services are realized through a special class of components, service components. Service Components not only provide the functionality for the services, but is a monitoried, managed enterprise-scale asset that is a governed, funded component. A Flow or process is used to choreograph/orchestrate services. Sometimes, a process is composed of a combination of services and hard-coded parts of the process; for performance or funding reasons, not every bit of functioanlity is separated out as a distinct service (e.g., a Web service).
Therefore, services have a service description that exposes their functional interface, but also has two additional elements reflecting the non-functional aspects of policies as well as the data model snippets they relate to, as depicted in their (input and output) messages. So services have a functional and operational side to them that are BOTH externalized so that they can be found, bound and invoked or applied (in the case of policy).
These three fundamental constructs must be identified, then specified in greater detail and then, finally, realized using some technology mapping. This process of service modeling is described in the Service-oriented Modeling and Architecture
The first glimpse at the relation between services, components and (flows) processes is depicted in this high level SOA Reference Architecture
Welcome to my Blog.
Spring is in the cool, Midwest morning air, (and despite the drizzle outside) birds are chirping away and I feel it's a good time to start things. I hope you will find the experiences I will be sharing with you informative or even interesting and worth your time.
Here, I will be sharing some observations, experiences and conclusions about SOA; on how/what things worked on projects (and were needed to succeed) in the modeling, analysis, design, development and management of service-oriented architecture.
I will share what things (e.g., practices, methods, etc.) helped the project succeed. After using them successflly a few times I like to think of these practices as "leading" practices. And then, maybe, after a while, when they work in several domains, we might call them "best-practices". But I'll also talk to you about "worst-practices" or "gotchas"; things that were counter-productive or that just don't work when you are building service-oriented architecture.
Everyone probably have their own definition of SOA; here's one that I like to use:
"An SOA is an architectural style that is reflected in an enterprise-scale IT architecture. It enables access to distributed resources, on demand.
An SOA consists of a set of business-aligned IT services that collectively fulfill an organizations business processes and goals. These services can be choreographed into composite applications and can be invoked through open protocols.
In an SOA, resources are made available to participants in a value-net ("eco-system") at various levels of granularity: enterprise, line of business or project levels.
The three fundamental constructs around an SOA are services
, enterprise components
that provide the functionality and quality of service for those services and flows or processes
that string the services together. The primary structuring element, however is the 'service'."
So that begs the question, "what's a service?":
is a [discoverable] software resource which has an externalized service description. This service description is available for searching, binding and invocation by a service consumer. The service description implementation is realized through a service provider who delivers quality of service requirements for the service consumer. Services can be governed by declarative policies. "
There are a lot of definitions out there, and what I have described is just one of them. If you need more detail or clarification, let me know. Definitions are, however, just a good starting point and we have to move on from there pretty quickly and get the job done :-)
Some key ideas are: service-oriented architecture is an architectural style
with some guiding principles about how to build more loosely -coupled, business aligned software that can adapt and be re-composed or re-configured to quickly meet new business needs. As an industry, we are maturing in that direction.[Read More