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.
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 .
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.
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.
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.
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?
Modified by Ali_Arsanjani
Microservices reminds us of very fine grained, tiny, micro-scopic services. Perhaps services that grow on a Petri dish.
But actually, they refer to a deployment pattern for services developed in a Service-oriented Architecture along the constraints of a Functional Area that owns its own Data, and does not allow access to its Information willy nilly. You start with a domain break it down into a Functional Area and get down to the subsystems and components living there, deep in the bowels of the legacy systems, the packages inhabiting the digital ooze in the sewers of legacy code , interspersed with some fresh sprinklings of new additions of components implementing newer services required by the business.
Stratified along a Functional Area, immune to the curious and invasive glances of strange components and outside systems, the service rests peacefully in isolated, independent deployment. Choosing to deploy to brew this SOA flavor with a twist of independent deployment, along the lines of a functional area, owning its information, is detailed out in the implementation of finer grained services in SOMA (Service-oriented modeling and architecture) ,many companys' service-oriented method.
Don't mistake this as the only way to choose to constrain SOA by design along functional area boundaries and deploy along those lines. This is only one brew of SOA.
Some considerations are the need to communicate between deployed services that are other wise feeling a little isolated and engaged heads down in their servicing of requested for their functional area of the business. But business have cross cutting concerns and dimensions, often exemplified by BPM or business process management. Cutting across silos or functional areas, the process needs access to various data sources and systems of record, albeit some are prehistoric gauging by enterprise standards.
Sp cross cross cuts of SOA flavor are best served by BPM. Smaller granularity focused functional area services by Microservices. What about when mobile needs to access something? Well for that we have the API brew. RESTful (Representational State Transfer) APIs provide an HTTP/S level of simplicity of access (yes, both get and set) that allow access to underlying functionality via mobile devices and yes Software-as-a-services, or Cloud as is known in slang.
So choose your brew of SOA according to your mood, according to what you would, contingent on what you should
be doing with your processes, data or business functions. Choose wisely for each have pluses and minuses; opportunities and consequences, like any pattern. Or brew.
Modified by Ali_Arsanjani
What are API’s critical to enterprise business agility?
Today we see the importance of a confluence of mobile, cloud-based, service-oriented applications that were hitherto locked within the enterprise break free and start interacting with an ecosystem of partners opportunistically in order to create value on emerging opportunities especially those provided by mobile devices, social business, big data and analytics and cloud-based services. It is important to understand the evolution of APIs in order to better capitalize on opportunities presented by the economical dynamics of an ecosystem connecting and communicating through APIs.
The evolution of APIs
API’s or Application programming Interfaces were initially thought to be libraries of reusable code. They were focused very specifically on providing functionality that was written one often to support a complicated set of granular operations such as a graphics library, telecommunications library, security etc.
In the first decade of the 21st century, application programming interfaces morphed because of service-oriented architecture. The protocols used to implement Web services in a service-oriented architecture were numerous. The simple object access protocol or soap was one means of access. This sort of replaced RMI over IIOP in a distributed computing world.
Service-oriented architecture taught us that not only does interface have to be separated from implementation but also that implementation can be separated out into several layers. One layer is a more abstract specification of where the endpoint for the service implementation may reside. Often an enterprise service bus was used to virtualized the endpoint so that the optimal endpoint could be selected based upon configurations or input parameters or more pragmatic considerations pertaining to security, scalability or performance.
Implementation was separated into a realization decision, And a deployment set of options. The realization decision was primarily governed by the question: “how am I going to implement the service? Which component is going to be used to implement the service functionality?” The component could be anywhere from a.net component, and enterprise JavaBean or a legacy application interface or even a package application. The deployment option included not only the protocol by which the implementation would be realized but also the configuration options pertaining to the infrastructure or platform used to ultimately operationalize the solution.
Representational State transfer or REST was a protocol created to support a very lightweight mechanism that would replace the more complicated SOAP protocol and therefore could use HTTP or HTTPS. Therefore the verbs that could be used where the familiar get and put actions familiar to web programmers.
Restful APIs were APIs that extended enterprise capabilities hitherto reserved for webpages into the ecosystem. This ecosystem of partners who were now able to interact using restful APIs, created the opportunity for an API economy.
The characteristics of API-based services
At the core of the enterprise the concept of service-oriented architecture suggested the creation of the service model. Within it is a service portfolio that is created, governed and managed as an enterprise asset. This asset , the Service Portfolio represents the implementation of business capabilities that the enterprise would like to expose experience brings of partnership and security either within the enterprise but also extending towards the edge of the enterprise and more selectively, beyond it, to business partners.
In summary characteristics of the API-based services provide the enterprise the ability to :
· Externalize Business Capabilities for ecosystem consumption
· Capitalization and monetization of Enterprise Assets outside the organization
· Extend value of Enterprise capabilities beyond the enterprise
· Secure access to internal enterprise resources and capabilities
· Enable channel-agnostic connectivity with business partners and consumers
Internally, the APIs will be part of the enterprise portfolio that can provide elimination of redundancy through reuse of capabilities as well as providing governance through consistency of created assets.
Externally, exposure of internal capabilities to the partner ecosystem will allow value-added services to enhance existing services provided, bringing in a new set of clients.
Pitfalls and Best-practices
Lack of alignment of an API to a clearly defined set of business goals can be detrimental to the adoption of the technology and capabilities behind the API.
APIs should not focus on time sensitive technologies or merely on fulfilling user interface capabilities that access backend systems. An example of this is to limit the capabilities of an API to CR UD-based operations such as create, read update and delete. This severely limits the capabilities of expansion of the API into higher levels of maturity of an application lifecycle.
Exposure of architectural decisions that stem from interorganizational considerations that in turn have sprung up over time as a result of the attempt to maintain the big ball of mod that constitutes the legacy systems that have been developed over generations within the organization. One best practice is to mask the convoluted interdependencies on technologies, architectural decisions that were made due to expediency and legacy platforms and the scars of partially successful mergers. The API should not expose such backend architectural decisions and implementation considerations just as any good service in a service-oriented architecture would mask these backend assumptions that have no rationale beyond the walls of the enterprise.
Secure a path of growth so your applications can start evolving from merely accessing backend legacy systems to performing transactions, initiating business processes and engaging in decision management.
Designing for the glass. Designing mobile applications is a current fad which is driven by the strong adoption of mobile devices. This can be a severely limiting factor is the application is designed from the glass in words in other words consideration of the backend business processes must be taken into consideration along with considerations of usability at the screen level for the mobile device of choice.
The ability to orchestrate and compose APIs in order to provide a mediated or orchestrated experience of the business process is a critical success factor with the maturation and increased adoption of APIs within your ecosystem.
Modified by Ali_Arsanjani
Context: Industry adoption of development, life-cycle and architectural styles such as SOA tend to be imported into organizations and then move from an evangelist, grass roots kind of effort into a next phase of organizational maturity which tends to impose rigid constraints on the life-cycle, standards, governance and development of the architectural style. SOA is an example.
Problem(s): High level , holistic design and architectural work is needed to provide contractual visibility to clients. Architectural styles (OO, CBD, SOA etc) are co-mingled with the rigor of the top-down governance that is seen to be required, or they are sacrificed for rapid, quick and dirty, "let's not look around the bend until we get to it" approach.
Forces: The developers tend to push back to the imposition of increasing accountability and governance in general, including standardized development practices. The organization , in an effort to be accountable to the business, requires increased tracking, metrics and accountability. Developers will continue to resist increased accountability due to the perceived imposition on their time that is deemed less valuable than the actual development of the product. Against this, accountability and project visibility, allowing projections in order to fulfill "promises" (e.g., contracts, SLAs, etc) with clients (whether internal i.em business as a client, or external, as in other organizations that services/products are provided to).
(Re)solution: Combine a light top down governance and standardized software development process/method that looks holistically but does not require detail to the n-th degree prior to engaging in a project or program, coupled with agile iterative sprints.
Consequences: High level visibility and accountability are attained with some compromise with the "let's just do it" approach. Development is not impeded with heavyweight constraints. Promises to the business or external clients have a reduced risk of non-completion associated with them.
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.