BPM, APIs & Service-oriented Architecture: Insights and Best Practices
Ali_Arsanjani 120000D8QB 7,022 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,165 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.
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.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 directly.
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 than implementation.
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 violated.
The promise of object orientation
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?
Ali_Arsanjani 120000D8QB 4,839 Views
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.
Ali_Arsanjani 120000D8QB Tags:  service-orientedcomputing maturity pervasive services 5,534 Views
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.