SOA Practitioners Guide

A few early adopters of SOA met last year back (August 2005) and agreed to establish an SOA community. This community was prelaunced at the Global Integration Summit (GIS) with the following proposed objectives.

• Get agreement on terminology for discussing SOA.
• Influence and deliver requirements to Standards Organizations and Vendors
• Provide education and rich understanding:
• Articulate & Promote Business Value Capture
• Disseminate Success Stories, Best/Worst Practices
• Offer templates, tool and methodology to ensure investment success

The same early adopters did publish the SOA Reference Architecture at the same event and continued working on documenting SOA best practice. As the SOA communitly was has not yet been formally launced early SOA adopters agreed to publish these best practices as SOA Practitioners Guides and are also available at my structured blog.

SOA Practitioners Guide (Abstract):

SOA is relatively new, so companies seeking to implement it cannot tap into a wealth of practical expertise. Without a common language and industry vocabulary based on shared experience, SOA may end up adding more custom logic and increased complexity to IT infrastructure, instead of delivering on its promise of intra and inter-enterprise services reuse and process interoperability. To help develop a shared language and collective body of SOA, a group of SOA practitioners created this SOA Practitioners Guide series of documents. In it, these SOA experts describe and document best practices and key learnings relating to SOA, to help other companies address the challenges of SOA. The SOA Practitioners Guide is envisioned as a multi-part colelction of publications that can act as a standard reference encyclopedia for all SOA stageholders.

The guide is available in three parts:

SOA Practitioners Guide Part 1: Why Services-Oriented Architecture? - This guide provides a high-level summary of SOA.

SOA Practitioners Guide Part 2: SOA Reference Architecture - This guide covers the SOA Reference Architecture, which provides a worked design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates and potential code assets from members.

SOA Practitioners Guide Part 3: Introduction to Services Lifecycle — This guide introduces the Services Lifecycle and provides a detailed process for services management though the service lifecycle, from inception through to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best practices, templates, comments on key SOA standards, and recommended links for more information.

Contributing SOA Practitioners:

• Surekha Durvasula, Enterprise Architect, Kohls
• Martin Guttmann, Principal Architect, Customer Solutions Group, Intel Corp
• Ashok Kumar, Manager, SOA Archtiecture, Avis Budget
• Jeffery Lamb, Enterprise Architect, Wells Fargo
• Tom Mitchell, Lead Technical Architect, Wells Fargo Private Client Services
• Burc Oral, Inidividual Contributor
• Yogish Pai, Chief Architect AquaLogic Composer, BEA Systems, Inc.
• Tom Sedlack, Enterprise Architecture and Engineering, SunTrust Banks, Inc.
• Dr. Harsh Sharma, Senior Information Architect, MetLife
• Sankar Ram-Sundaresan, Chief Architect e-Business, HP-IT

SOA Stakeholders

The industry as a whole has been attempting to define Services Oriented Architecture (SOA). The definition of SOA may wary based on the responsibility of the individual. It is therefore necessary to understand the responsibilities of the stakeholders before defining SOA. The following link to the document is an attempting at identifying the various stakeholders.

http://www.soablueprint.com/whitepapers/SOAStakeHolders.pdf

Enterprise Architects - Roles and Responsibilities

As companies are starting to adopt SOA, one of the questions they keep attempting to answere is "what are the roles and responsibilities?" of an enterprise architect. My thoughts on the role of an enterprise archtiect are available at http://www.soablueprint.com/whitepapers/EARolesAndResponsibilities.pdf

Return of my Blogs

I started blogging early last year, initially by blogging at this site and later at the site provided by my employer. I soon realised that unstructured blogging is not for me, especially as I prefer to make my case in a structured fashion. At my structured blog (it is technically still unstructured data - organized in a way it makes sense to me). I have been planning to roll this out since last year and finally reached a decent starting point. I shall keep adding new content and post the description at this blog for reference.

Direction for the SOA Wave

The Fourth Wave Barreling In

The impact of SOA, the fourth wave of enterprise IT, has gone way beyond the early adopters. Leading research reports show that the vast majority of CIOs and CTOs have formally explored, and in many cases begun implementing, pilot initiatives. Recent surveys conducted by InfoWorld, Yankee Group, Webservices.org and others show that over 75% of CIOs have investigated and are planning SOA investments in the next 12 to 18 months.

Despite the growing enthusiasm, SOA lacks many of the shared experiences, artifacts and patterns required for widespread and reliable IT adoption. Moreover, without a common language and industry blueprints, this wave, which promises benefits of intra- and inter-enterprise services reuse as well as process interoperability, will dissipate and eventually fizzle – ultimately only adding more custom logic and methodologies to the IT legacy. Directing the SOA wave so that it can live up to its potential requires user community leadership.

Read more about this at http://dev.bea.com/arch2arch/soa_wave.jsp

Recommended Approach to SOA

It is the best of times, it is the worst of times, it is the time of service-oriented architecture (SOA), it is a time of traditional development methodologies, it is a time when products have matured, it is a time when products don't exist yet, it is the season of the optimist, it is the season of pessimist. We have endless possibilities in front of us, but we are concerned about being irrelevant. We are going to achieve the state of nirvana, we are going directly the other way—in short, this is a huge opportunity for IT to demonstrate its true value.

Read more about this at http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html

SOA Stakeholders

Indentify the SOA stakeholders for crafting the right message tothem.

Copy of my post at: http://dev2dev.bea.com/blog/YogishPai/archive/2005/09/soa_stakeholder.html

The consistent feedback I have been receiving over the past few months is requesting for a consistent definition of SOA. The messaging shall wary based on the target audience and is key to getting buyin to adopt SOA enterprisewide.
I shall attempt to identify the key SOA stakeholders and shall post the proposed messaging is the subsequent blogs.

IT "Board of Directors" Just like every organizations has a Board of Directors, IT needs one too. Typically this function is performed by some key executives or by their representatives. The Board's objective is to set direction, approve initiatives/projects, resolve conflicts, etc. Some organizations refer to these boards as ISSC (IS Steering Committe), ITRB (IT Review Board), etc.

Chief Information Officer (CIO) Head of the IT organization - responsible for all aspects of IT.

Chief Technology Officer (CTO) Responsible for Enterprise Architecture within IT. This has been a recent trend for creating this position in IT organizations.

Program Management Office (PMO) The PMO is responsible for orchestrating the projects across the enterprise or LOB. Ensure that the standard process defined by the Enterprise Architects is followed by each of the project teams and is primary contact for all Project Managers for cross-functional activities.

Architects
Multiple categories of Architect
Enterprise Architects are responsible for defining the standards, proces, design paterns, identify new technology, etc.
Projects Architects are responsible for the design of a particular business solution/application.
Information/Data Architects are responsible for ensure that there is a consistent information/data approach & model accross the enterprise.

Business Sponsor is someone from the business who champions the applicaiton within the business and is ultimately responsible for ensuring that the projects is successfully adopt within the enterprise. This person is generally responsible for securing the funding, business transformation and is generally also an officer (VP or above) of the company.

Business Operations teams are resposible for defining and documenting the operations proccesses. Ensuring that the deinfed processes are followed within their area of responsibility and are also the key point of contact for the frontline person of that business unit. Example: Sales Operations is responsible for ensuring that all submitted orders by the sales is reviewed and accepted.

Archtiecture Steering Committee. There is a steering committee for every projects or program and there needs to be one for enterprise archtiecture too. The members of this committee are the IT Leadership Team and key stakeholders from business operations.

Shared Services Responsible for developing the shared services for the enterprise or LOB. Multiple models exists - dedicated shared services team, shared services being part of the Archtiecture team, shared services developed by each project team (like open source).

Project Managers Responsible for delivering the project on-time, under budget and could be either from business or IT. Best practices are to have one person responsible for project delivery but have seen model where a business PM is paired with the IT PM for getting the project delivered.

Data Center Operations Responsible for the data center and keep all the applications up and running.

Application Support Multiple models - Dedicated centralized team, dedicated application support team within a LOB, permanent project team with developers rotating to application support role, outsourced, etc.

Please note - the objetive is to identify the SOA stakeholders and may not have done justice to the job decriptions. Hope to spark up a discussion - so please feel free to add your comments. Expand on the job desciptions, etc.