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
Monday, July 24, 2006
Monday, July 10, 2006
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
Monday, June 05, 2006
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.
Tuesday, December 13, 2005
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
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
Tuesday, October 11, 2005
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
Read more about this at http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html
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.
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.
Wednesday, August 17, 2005
Is ESB the same as an EAI?
The fundamental question that a lot of folks are asking is whether ESB (Enterprise Service Bus) the same (or the next Generation of) as EAI (Enterprise Application Integration). My response to this is no:
EAI is still appropriate wherever it makes sense (but I would not take this approach any more). The architecture approach is ADAPTOR-->TRANSFORMATION--->BUSINESS PROCESS -->TRANSFORMATION--->ADAPTOR which leverages EAI tool like TIBCO, WebMethods, WLI, etc. Is this truly SOA? No! - it is basically a point-to-point implementation on a Hub. The developer of the process need worry about all the protocol translation, routing, etc. and this is generally tightly coupled with the business process.
ESB on the other hand decouples the protocol translation, message/event routing, limited message validation, etc. and is targetted for use by IT Operations. Developers need not worry about all these details, which makes it faster to roll out new services. However, to make this a vaiable approach within an enterprise, there
is definitely a greater emphasis on architcture.
The ESB also enables servcie abstraction at various levels, thereby enabling multiple teams to develop a particular service. In addition, with it's integration with the Service Registration and Management Capability it definitely makes it easier for IT Operations to track and provide the SLA requested by the business. The above diagram illustrates (Source: Paul Patrick - Chief Architect for Services Infrastructure, BEA Systems) how the ESB enables creating a grid within the enterprise - allowing each business unit / organization to grow at their own pace.
EAI is still appropriate wherever it makes sense (but I would not take this approach any more). The architecture approach is ADAPTOR-->TRANSFORMATION--->BUSINESS PROCESS -->TRANSFORMATION--->ADAPTOR which leverages EAI tool like TIBCO, WebMethods, WLI, etc. Is this truly SOA? No! - it is basically a point-to-point implementation on a Hub. The developer of the process need worry about all the protocol translation, routing, etc. and this is generally tightly coupled with the business process.
ESB on the other hand decouples the protocol translation, message/event routing, limited message validation, etc. and is targetted for use by IT Operations. Developers need not worry about all these details, which makes it faster to roll out new services. However, to make this a vaiable approach within an enterprise, there
is definitely a greater emphasis on architcture.The ESB also enables servcie abstraction at various levels, thereby enabling multiple teams to develop a particular service. In addition, with it's integration with the Service Registration and Management Capability it definitely makes it easier for IT Operations to track and provide the SLA requested by the business. The above diagram illustrates (Source: Paul Patrick - Chief Architect for Services Infrastructure, BEA Systems) how the ESB enables creating a grid within the enterprise - allowing each business unit / organization to grow at their own pace.
Subscribe to:
Posts (Atom)