Wednesday, September 07, 2005

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.
Post a Comment

Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!

A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...