- David Linthicum's article
Getting the Links Straight Between Cloud Computing & SOA from Sys-Con's SOAWorld. Gray Hall's blog entry Cloud Computing Unleashes the Potential of Service Oriented Architecture comments on David Linthicum's article and takes things a step forward. Joe McKendrick's article Why SOA really, really matters in a cloud computing world at ZDNet. The Gartner report Cloud Computing Will Cement the Mainstream Role of SOA by Yefim V. Natis, W Schulte and Massimo Pezzini puts cloud computing and SOA in perspective (you have to pay for it if you're not a Gartner client, btw).
- Doug Tidwell's article: https://www.ibm.com/developerworks/mydeveloperworks/blogs/doug_tidwell/entry/cloud_soa_zero2?lang=en
Data Science, Machine Learning & API / SOA: Insights and Best Practices
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:
Towards a more precise definition of Business Agility: The Building Blocks of Business Agility (B3A)
Ali_Arsanjani 120000D8QB Tags:  building_blocks_of_busine... agility business_value business b3a 5,517 Views
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
There 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 Entities model and reflect the key business domain elements of the Business Eco-system that under Business State changes.
Many EA (Enterprise Architecture) practitioners are …exploring the links between desired business outcomes and architectural decisions.
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.
Instrumentation and mechanisms to monitor, track, help modulate and govern business change as key performance indicators track the events and occurrences within the Business ecosystem Context.
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:
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 performance (efficiency).
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.
Ali_Arsanjani 120000D8QB 4,500 Views
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,
Ali_Arsanjani 120000D8QB 7,898 Views
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.
The book is entitled 100 SOA Questions: Asked and Answered .
I have started a separate blog at soaquestions.blogspot.com to discuss further questions and comments specifically about the book .
Ali_Arsanjani 120000D8QB Tags:  sustainable adaptive performance agile business_performance business 7,714 Views
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?
When Service identification Becomes Critical: Service Proliferation Syndrome and Service Interface Changes
Ali_Arsanjani 120000D8QB Tags:  service_portfolio governance service_proliferation service_model service_monitoring soma 13,913 Views
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.
Ali_Arsanjani 120000D8QB 5,049 Views
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".
Ali_Arsanjani 120000D8QB 7,811 Views
Architectural Paradigms of the Future Part 2: Eco-system Architecture engulfs Enterprise and Business Architecture in the Cloud
Ali_Arsanjani 120000D8QB Tags:  service-oriented-architec... enterprise-architecture business-architecture eco-system-architecture 14,734 Views
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:
That is, while we value the items on the right, we value the items on the left more.
We follow these principles:
© 2009, the above authors, this declaration may be freely copied in any form, but only in its entirety through this notice.