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]
BPM, APIs & Service-oriented Architecture: Insights and Best Practices
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]
Ali_Arsanjani 120000D8QB 1,962 Views
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]
Ali_Arsanjani 120000D8QB 1,664 Views
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]
Ali_Arsanjani 120000D8QB 2,414 Views
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."
Ali_Arsanjani 120000D8QB 2,262 Views
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]
Ali_Arsanjani 120000D8QB 1,838 Views
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]
Ali_Arsanjani 120000D8QB 1,098 Views
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]
Ali_Arsanjani 120000D8QB 1,026 Views
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 end-to-end
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?
Ali_Arsanjani 120000D8QB 962 Views
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.
Ali_Arsanjani 120000D8QB 1,201 Views
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.
Ali_Arsanjani 120000D8QB 947 Views
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!
Ali_Arsanjani 120000D8QB 1,023 Views
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]