SOA:Many Things!

SOA: Many things

SOA is not one but many things! Recall the story of blind men and the elephant; each one comes up with a different interpretation. Our individual perceptions and role in an organization is not an adequate basis to describe the entire SOA beast. Agendas of individuals or organizations defining SOA make it even harder to fathom through the myriad. For instance, for a vendor with a product line of applications, SOA is just web services. For a technologist, it is an IT issue and all about SOAP. SOA is about legal contracts for the general counsel, or delivering a business capability for a CIO.

In short, SOA means many things to many people. Yet we are not blind and should not be constrained by a narrow view. Thus the overall definition of SOA must arise from collective nature of the enterprise, with input from its constituents.

Let’s consider a situation involving the return of unused goods. In this typical reverse logistics scenario, understanding of a service varies from technologists to non-technologists, each with different priorities. For a technologist, a service is a network-enabled software component, which provides a specific capability. For a non-technologist, a service is some form of offering supplied by an organization that receives merchandise return requests, sends directions for shipment, updates inventory and applies credit to the customer. A customer service representative will make sure that customer requests are understood and s/he gets the information for the return. Shipment and receiving will be your focus if your role is operations. Accounting will be more interested in applying appropriate credit to the customer. While each participant has a defined focus, overall goal is to establish a means of delivering value to the customer.

This complex situation involves Customer Relation Management, Supply-Chain Management, and Enterprise Resource Planning. SOA solves this complexity by

• Decomposition
• Aggregation
• Orchestration

SOA decomposes this business process into well defined discrete services: some are automatic, some are manual, some short-lived and near real-time, some are long-running requiring human-intervention. Services may be aggregated and then orchestrated to create additional services depending on the granularity level of decomposition.

After all, a service is a unit of work done by one entity in order to meet the need of another entity. The primary entities in SOA are the service provider and the service consumer. At any point, the roles may be reversed, consumers becoming providers and vice versa. The consumer enjoys the value created by service without the ownership of the specific costs and benefits.

Service interactions, however, must be defined unambiguously for both entities to successfully communicate. Each interaction between the participants must be self-contained in a service contract, focusing on a specific capability. A greater synergy is achieved by the orchestration of these services in a coherent manner.

SOA embraces the fact that each entity may have a drastically different environment. Distinct systems or applications deployed at various agencies can interoperate because SOA makes as its pinnacle the use of ubiquitous XML which poses no limitation by platform or language. Choosing JAVA, .NET, or a mixture is not a headache anymore! By placing emphasis on business activity rather than implementation details, SOA can make that crucial inventory drop arrive at a warehouse manager’s Blackberry™ to shore up just-in-time measures. By adhering to the service contract, an organization can easily swap out its implementations or move to other locations. A service for sending out information to customers, for instance, may be reused by multiple departments.

SOA is more than a buzzword. It is the way for organizations to rapidly develop capabilities, to collaborate and meet the expectations of their stakeholders. SOA’s agility makes it an enterprise business strategy, however.

SOA may also be DOA, dead on arrival, if we narrowly assume that it is just a bunch of web services, a product or a panacea for integration nightmares.

Some organizations get their feet wet with a few services by creating prototypes and exploratory projects. This is a good point of entry for the technologists but the business executives need to start thinking big at the onset. For businesses, a concerted effort needs to be made to launch a SOA lifecycle at the enterprise or the segment level. A typical SOA lifecycle includes three stages:

• Initiation
• Roadmap development
• Plan execution

For continued success, the lessons learned in execution should create a feedback loop to the roadmap.

SOA initiation needs both business and IT to cooperatively decide on the business process that will be built or replaced. Creating the team and setting a project plan is necessary. Roadmap development establishes the SOA principles and reference architecture for business and technology (application, data, and infrastructure). Governance will guide with policies, measure effectiveness, control for compliance, communicate to inform all parties, and above all, empower for better decision making. Program management assures that the project is on time, on budget and on scope.

The SOA lifecycle is about implementing SOA enterprise-wide. It gauges smaller pilot projects to be on par to address the need of the organization and paves the way for properly scaling up. Once business and IT decide on the services, avoiding DOA requires establishing a Service Lifecycle to manage individual services.

Service lifecycle spans the activities from inception to retirement or decommissioning of a service. There are three stages:

• Requirements and Analysis
• Design and Development
• IT Operations

Following a service lifecycle assures accurate capture of business requirements, development of IT solutions that match business requirements and deployment/maintenance of services that provide business capabilities encapsulated in the requirements.

Starting a SOA lifecycle, or for that matter, choosing the candidate business processes along with governance, is not a small feat. A misfiring engine can cause headaches in the long drive. Choosing a vendor in this endeavor may be the biggest investment an organization may have to make in climbing the mount SOA.

Note that SOA is neither a product nor a single solution, but rather a comprehensive business enablement with IT elements. Make sure that your vendor is capable of bringing together business and IT stakeholders in a face-to-face collaborative where you, as an organization, not the vendor, make the decisions. After all, who knows your organization better than you? How rapidly will your vendor comprehend and assess your business processes to enable you to sail into service decomposition? Think big and ask about the end game. Establish governance and a program management. Spot the need to change early, especially organizational changes. Start small with services representative of your environment then you are ready to scale fast!

Burc Oral

http://www.linkedin.com/in/burcoral
http://www.soa-consortium.org/

SOA Consortium: Keynote by Amit Sinha (plus 2nd day comments)

Amit Sinha, VP Portfolio Marking from SAP presented the key note on the second day of the SOA Consortium face to face meeting held last week at Burlingame, CA. The topic he presented was on Business Network Transformation and following are some highlights from his presentation:



Most of these observations were based on the survey of over 175 CIOs globally. The trend has been that IT organizations are transformation themselves from Operational Excellence to Business Agility which in tech speak would be from Integrated Enterprises to Business Networks. Instead of developing solution based on the "Built to Last", the IT solutions now being considered (funded) are being "Built to Adapt".



Following are the top three approaches adopted by the various IT Organizations:

1. Managing Relationship (Single view of the customer, customer focused solutions, etc.). 23% of those surveyed adopted this approach which resulted in approximately 7x growth / year
2. Cost Containment (IT operational excellence, Off-shoring, BPO, etc.) 23% and the results are well know in the industry
3. Business Process Innovation (change the business model) 14% surveyed are adopting this approach and are consistently observing 2x the growth compared to the industry

In short - SOA is actually a catalyst for Innovation.

Following the key note we spent the rest of the day discussing the SOA Planning Framework, SOA Center Of Excellence as well SOA Skill sets required. One consistent theme throughout was that there is a desperate need of people with excellent Business breadth and deep technology skills - also referred to as the T shared person by Sandy Carter (IBM).

An observation while reviewing the EA 2010 presentation:

Improving IT Efficiency: 2% improvement to the margin

Going through Business Transformation: 8% improvement to the margin

Adopting SOA that facilities both Business and IT transformation: 20% improvement to the margin

Having an Enterprise Architecture team with both Business and Technology Architecture Skills: Priceless

- Yogish

Best Practices - Is Canonical XML dying? - Reply to IC Blog

This posting is a reply to the blog posting on Canonical Model http://www.icmembers.org/blog/zaki/2007/10/5/is-canonical-xml-dying#comments



In general, I agree with the posting on Canonical XML discussion. I wanted to make a couple of additional comments on industry-vertical specific Canonical models and the benefits they offer to those enterprises whose interactions leverage standards based information exchange.



a) implementations leveraging package products that exchange canonical models expressed in XML allow ease of upgrading and/or switching between package products without paying a huge upgrade penalty. This is so in the case of functionality related upgrades that do not alter the service definition and/or the information exchanged. Also, this makes decommisioning of redundant packages easy when this becomes necessary during acquisitions long as the package implementation are all standard canonical XML based.



b) partner collaborations also become easy, reliable and robust when collboration is based on the use of common industry vertical XML representations. Adding more trading partners becomes easy when using standards based information representations and this in turn leads to predicatable interaction patterns and information exchange.



c) documentation that refers to common service interactions that form the basis of that industry vertical when captured in training artifacts enable standardized interpretation of the material. In addition, given that this type of training is transferable between enterprises belonging to that industry vertical sharing personnel among trading partners is also made simpler.

Your comments on the canonical model usage is appreciated.
surekha -

SOA Consortium: Keynote by Sandy Carter

The SOA Consortium's last 2 days face to face meeting for 2007 is currently underway at Burlingame, CA. Yesterday, Sandy Carter gave a keynote address to the attendees and following is a brief summary of her comments:

Every two years, IBM conducts an exhaustive CEO survey (a couple of hours conversation with each of the CEOs) which is published every two years (last years report is available here). The next report shall be published next year around April at their IMPACT event. Following are some of the interesting findings:

Business have notices a 2% improvement in their revenue by focusing on IT optimization and an 8% improvement by focusing on business optimization. However, when they align both IT and Business, the impact was more than double, 20% a key reason for enterprises to focus on Business Agility.

The top four areas of focus for CEOs (in no particular order) are:

a) Agility
b) New and changing customer
c) Business Model Innovation
d) SOA (Yes! looks like SOA had now made the CEOs priority list)

As there is no real way of measuring agility, IBM has coined a new term KAIs (Key Agility Indicator). This is similar to KPIs (Key Performance Indicators) and they do have a tool that allows to benchmark your results to the 12,000 company data that they have compiled.

I like the concept of the KAIs and agree that what IBM had done is great job putting together a tool that allows enterprises to benchmark themselves against the industry. However, I believe that there is a need for a simpler way to measure your own agility (an art and a science) and it for this reason, I had taken a crack at the Business Agility domain model. Hope to define the maturity levels for each of the Business Agility domain model to enable business that do not have access to IBM's KAI tool.

As for new and changing customers - I agree things are changing at such a rapid pace, it is difficult to keep up, especially with the new social networks tool which shall rapidly enter the enterprise market. Hey! I just looked at Loopt and realized one could use such as tool for logistics and asset tracking.

Business Model Innovation is happening now, especially in large enterprises. Examples: Cisco moved from direct sales model to channel sales model. Oracle's model now has changed their business model from being a technology leader to an aggressive acquirer. And of-course we have companies like Google, Facebook and LinkedIn that have changed the way we search and collaborate.

SOA Consortium – Ground Floor SOA – Recap for 07

The most significant progress we on the SOA Consortium Working Group of "Executing Business Driven SOA" have made in the past year was in the definition of the SOA Planning Framework. Efforts undertaken as part of the SOA Planning Framework track will include classification and logical grouping of the collective body of work done thus far by the Strategy 2 working group; thereby allowing us to deliver a single document that can be used as a reference by anyone who embarks on the path to SOA-enable their enterprise. This includes work done under the headings of “SOA Readiness Assessment”, “SOA Opportunity Identification” and “High Level People, Process and Tools” matrix. All of this material will find a home in the various sub-components of the SOA Planning Framework. Once completed the SOA Planning Framework will be one of the most comprehensive guidelines for those looking to implement SOA.

The other key benefit of the SOA Planning Framework deliverable is that it allows an enterprise to start on one or more of these components without forcing it into having to define all components prior to getting started on the SOA Roadmap. This is where the SOA Planning Framework differs from that of a rigid SOA methodology - in that it is a loosely-woven collection of SOA enabling constructs.


Again, I would like to thank you of the members of Strategy 2 for your participation and invaluable input. I look forward to a very productive upcoming year.

surekha -

Selecting Strategic Projects

Continuing on my thoughts on aligning project portfolio to IT strategy, what are some of the criteria one must use for selecting projects that are truly strategic. A number of organization may use the size of the project to tag it as a strategic project. In my opinion, one must ask following questions to see if a project fits the definition of a strategic project:



- Is the project adding new capability or enhancing an existing capability in one of the core business processes. A core business process is one related to enterprises' primary value chain (excluding, HR, Finance, Facilities etc.).

- Is the capability shareable across many processes. For example a capability to have a full view of customer relationships can enhance not only sales, marketing and customer service processes but can also be used in other key processes such as supply chain management.

This is all I can think of right now. Would be interested in hearing other thoughts

Ashok Kumar

Key Lessons – The new and improved Enterprise Architecture Group

When invited to start the Enterprise Architecture Group a couple years ago my only thoughts were how to technologically implement SOA and EDA as the core architectural principles. However, soon enough came the realization that without having access to those who had sound business knowledge and those that knew the core business domains, value streams and the strategic business capabilities it would not be possible to effectively deliver SOA or EDA.


Service orientation of business behavior encapsulated in business applications and the definition of business events that initiate key business processes both require enterprise-wide understanding of business behaviors and business activities. Furthermore, the ability for identifying business services and/or business events comes from being able to abstract business needs that cross business domain boundaries. These skills can be found in a group of individuals being called business architects – a unique group of individuals who can translate the strategic business needs into an action plans that show how to enhance current business processes that support core value streams.


This led me to find resources that could analyze business processes (a.k.a. Process Architecture discipline) and resources that could analyze business information-flow, the value-addition pathways (where by business information is enhanced as it is exchanged across multiple business domains) (a.k.a. Information Architecture discipline). Both sets of these resources have allowed me to embark on true SOA style service definition. So the “new and improved” Enterprise Architecture Group has Process Architecture, Information Architecture (or what the industry calls Business Architecture) and Technical Architecture representatives.


Finally a note about the Technical Architects; my opinion is that, standards are vital but then if the Enterprise Architecture Group is unable to demonstrate the right use of standards in a true production environment this group will be left with very little credibility or be deemed the “ivory tower” group.


Having a cross-functional group of resources has made the Enterprise Architecture Group to be a well rounded group. The Business Architects of the group are in dialogue with the business as they can speak to the business in its lingo while the Technical Architects of the group are able to work with the developers as they are able to demonstrate the use of technology for building and delivering stable, performant and reusable services. The end result is that the individuals of Enterprise Architecture Group are openly invited to the table for consultations and recommendations.


I would love to hear of other organizational patterns/ formats that have enabled implementation of SOA and EDA.

Thanks.
surekha -

Integration at Home - SOA Architecture

An article describes how integration at home works - integrating PCs, Game consoles, storage, etc. as well as handling multi-media and home automation. This same approach is also very relevant to the services approaches for enterprises. Read more about this iin my this month's DMReview column on Integration at Home - SOA Architecture.

For those in the Silicon Valley - DAMA and the Integration Consortium (IC) have joined forces to bring together their respective organizations to offer a 1 day meeting to explore Data Management & Integration. Presentations from thought leaders from each organization. Additional details are available on IC web site at http://icdama.icmembers.org/.



- Yogish

Aligning Project Portfolio to IT Strategy

How an enterprise derives value from its IT organization greatly depends on the way IT manages its project portfolio. The projects should be funded, based on a well defined strategic direction that is in line with long term business objectives. The reality is that majority of projects are primarily undertaken to alleviate a major pain point or to deliver some functionality quickly to gain some competitive advantage or worse as a result of some internal politics. This problem is specially acute in organizations with large legacy systems where there is built in resistance to change and general tendency to be risk averse.

In my opinion, IT organizations must make a deliberate effort to make sure a percentage of IT budget is invested in projects that are strategic in nature. This also implies that both business and IT strategies exist and IT and business community have a common understanding of what it is and have a deep commitment for its success.

Blueprinting Information Architecture and BPM

Following my blog on Key Learning: Blueprinting Information Architecture is key to successful adoption of SOA one of the feedback was Don't we need to define the detailed business process to identify potential service candidates?

My response to that is No and explained it in this edition of the Strategic IT Update. Please click here for all the Strategic IT Update presentation and transcripts.

Reference: Customer Data Integration: BEA-IT Case Study (my presentation at CDI Summit in 2006)

Best Practices - Mashups and the importance of Foundation Business Services

It seems like interactive web based social computing experience and SOA style services are not really thought of as related. However, when mashups are incorporated into the realm of the enterprise the need for ease of collaboration as well as accuracy tend to matter and this is where enterprise worthy services enter the picture.

In addition, having access to a registry is key. This SOA based infrastructure component becomes the central point for discovering loosely-coupled services that encapsulate core business functions and business semantics. To fully enable the knowledge worker in the selection of services for mashups, the business user community not only has to be included in the definition of the service but it has to be involved with the process of publishing these services to the registry as well. The reason being that business keywords that are used in describing the service are identified and entered when publishing the service to the registry. This level of cooperation and collaboration with the business user insures that the services are described using business language and grammer.

Finally, cross-business service payload validation behavior has to be put in place to prevent users from creating mashups that combine incompatible services. For instance, only services sharing related business contexts or those that return information at the same level of granularity should be allowed to be pulled together. Tools/ IDEs of the future that aid in the creation of mashups may be able to interrogate the categorization of business oriented services and informational metadata descriptors published into a registry or a repository to make a determination of inter-service compatibility. In the near term however, an enterprise will have to resort to governanace and testing policies to allow compatible types of services to be mashed up.

As can be seen in an enterprise context users can gain the capability to perform effective mashups when they can leverage reliable foundation services to access enterprise information systems. This way IT can enable user self-service by just making core services available to the knowledge worker and enhance business agility.

Your feedback is invaluable.
surekha -