IBM is spending millions of advertising dollars on promoting what they call as smart SOA. After ignoring for so many months, I finally decided to look into it. Following are my notes that are trying to capture the essence of smart SOA without any IBM advertising!
Smart SOA is a set of guiding principles based on IBM's thousands of real-life deployments and experiences with SOA. IBM defines four approaches for adoption of SOA: Fundamental, Extend End-to-End, Transform and Adapt Dynamically. Fundamental approach involves departmental, very focused projects to meet an individual business need. IBM has defined five entry points as the means to pursue this approach viz. reuse, connectivity, people, process and information. Projects associated with Reuse entry point typically involve creating reusable service-based business components out of existing IT systems. The connectivity entry point links people, processes and information in the business through the use of an intermediary service gateway or bus. The people entry point improves productivity by aggregating services as views, as well as enabling human interaction in the context of the business process. Common projects associated with process entry point include automating and optimizing manual business processes and human workflows. Finally the information entry point provides access as reusable services to complex, heterogeneous data sources within an enterprise.
The Extend end-to-end approach involves collaboration between business and IT to optimize and bring greater innovation to business processes that span the organization and extend beyond it. BPM enabled with SOA along with maintaining integrity across the processes is a major component of this approach. The Transform approach is a broader approach than the earlier ones as it involves using technology for strategic advantage. It is about innovating the business model itself as opposed to the individual end-to-end business processes through which that business model is implemented. Finally Adapt Dynamically approach involves creating a predictive business that responds to market forces in a semi-automated, intelligent way. It embeds a belief that the emerging ideal of rapid transformation in a semi-automated way will become increasingly possible as a critical mass of service providers in the ecosystem adopt SOA to enable the business to respond with agility to business opportunities.
IMHO, the first approach is the one which will be used by majority of enterprises as of today. Few innovative companies will go for second or third approach. The fourth approach seems to be quite futuristic though it provides a grand vision for SOA adoption.
Showing posts with label SOA. Show all posts
Showing posts with label SOA. Show all posts
Monday, 3 November 2008
Monday, 3 September 2007
Introducing Service Component Architecture (SCA)
David Chappell has written an excellent introduction to SCA in a whitepaper hosted on his site. Let me share my notes on this whitepaper in this blog.
SCA defines an approach for creating components and for describing how these components can work together to develop an application. There are three primary constructs in SCA: component, composite and domain. The components can be combined into a composite and a aggregation of composites makes a domain.
Components are the atoms from which an SCA application is created. It is an instance of an implementation, which is appropriately configured. The implementation may be in Java or in BPEL or in any other programming language. The configuration is expressed as XML in the language called as Service Component Description Language (SCDL).
Each component comes with a set of services, references, properties and sometimes bindings. It implements some business logic, which gets exposed as one or more services. To provide the necessary functionality, it invokes references, which are nothing but services of other components. Components can also make use of properties, the values it can read from SCDL configuration file when it gets instantiated. A binding needs to be specified for a component when it needs to communicate with a non-SCA application or with a component from another domain. the kinds of bindings include web services binding, JMS binding and EJB Session Bean binding.
Composites can be said to be molecules of SCA applications. The SCA Assembly Model specification defines how components can be wired to make up composites. While developers can use the GUI-based tools to wire together the components, ultimately these wirings get expressed as XML in SCDL configuration file.
SCA Policy Framework specification is used to define two categories of policies. Interaction policies can be defined by developers to modify how a component interacts with another components, in terms of security and reliability requirements. The Implementation policies are to be specified to modify how the component behaves locally.
While specifications provide a starting point, what is required for adoption are developer tools and runtime. While almost all vendors except Microsoft are gearing up for providing both developer tools and runtime, we will also have open source alternatives. While Apache Tuscany and Fabric3 from codehaus represent open-source options for runtime, Eclipse SOA Tools Platform (STP) Project is engaged in developing SCA tools for developers.
It's very unlikely that organizations can start using SCA now. I feel SCA will be considered by user organizations for adoption only after ratification of SCA specification by OASIS. Till then, we will need to watch its evolution as it indeed provides a latest state-of-the-art approach for software application development.
SCA defines an approach for creating components and for describing how these components can work together to develop an application. There are three primary constructs in SCA: component, composite and domain. The components can be combined into a composite and a aggregation of composites makes a domain.
Components are the atoms from which an SCA application is created. It is an instance of an implementation, which is appropriately configured. The implementation may be in Java or in BPEL or in any other programming language. The configuration is expressed as XML in the language called as Service Component Description Language (SCDL).
Each component comes with a set of services, references, properties and sometimes bindings. It implements some business logic, which gets exposed as one or more services. To provide the necessary functionality, it invokes references, which are nothing but services of other components. Components can also make use of properties, the values it can read from SCDL configuration file when it gets instantiated. A binding needs to be specified for a component when it needs to communicate with a non-SCA application or with a component from another domain. the kinds of bindings include web services binding, JMS binding and EJB Session Bean binding.
Composites can be said to be molecules of SCA applications. The SCA Assembly Model specification defines how components can be wired to make up composites. While developers can use the GUI-based tools to wire together the components, ultimately these wirings get expressed as XML in SCDL configuration file.
SCA Policy Framework specification is used to define two categories of policies. Interaction policies can be defined by developers to modify how a component interacts with another components, in terms of security and reliability requirements. The Implementation policies are to be specified to modify how the component behaves locally.
While specifications provide a starting point, what is required for adoption are developer tools and runtime. While almost all vendors except Microsoft are gearing up for providing both developer tools and runtime, we will also have open source alternatives. While Apache Tuscany and Fabric3 from codehaus represent open-source options for runtime, Eclipse SOA Tools Platform (STP) Project is engaged in developing SCA tools for developers.
It's very unlikely that organizations can start using SCA now. I feel SCA will be considered by user organizations for adoption only after ratification of SCA specification by OASIS. Till then, we will need to watch its evolution as it indeed provides a latest state-of-the-art approach for software application development.
Sunday, 2 September 2007
Business agility explored
While discussing SOA adoption, we believe that SOA is needed for achieving business agility. However, at the same time, we find our understanding of business agility is limited. We understand that business agility means the ability of business to respond quickly to the ever changing needs of environment in which it operates. It also means how quickly the business can launch new products, enter new markets or respond to new regulations. However, beyond this understanding of business agility, we stop to explore.
An article from the Research Briefing 2006 of MIT Sloan CISR would perhaps help us in understanding more about business agility. In this article, authors Jeanne W Ross and Cynthia M Beatch, have defined agility as the set of possible business initiatives a firm can readily implement leveraging pre-determined competencies with managed cost and risk. Based on their research, the authors have identified seven types of business agility, which they have grouped into three categories. These categories and the types are as given below:
Business Efficiency agility attempts to identify repetitive processes and extract unnecessary cost and time. The continuous improvement agility is more found with commodity businesses such as consumer product manufacturers. Such organizations are required to implement continuous improvement initiatives for accelerating profitability while reducing business risks. Scalability agility is the ability to rapidly scale up and down in response to changing business volumes. This kind of agility is almost must for companies from the Property and Casualty (P&C) Insurance industry as they would experience extraordinary demand for claim processing after natural disasters. The key organizational characteristics that would help to achieve the Business Efficiency agility include the following:
The speed with which organizations are required to respond to new customer demands and competitive challenges have gained increased importance for market responsiveness agility. Unlike Business Efficiency agility, Market Responsiveness agility disrupts, builds and reuses core capabilities. Interestingly, even if processes must change, companies benefit from developing clearly defined, standard operations processes and related data. Standardized IT Environment also helps in providing the foundation for new processes and interactions. Most notably, matrixed management structure helps companies introducing new capabilities without discarding old capabilities.
Organizations with boundary spanning agility have competencies enabling profitable growth through their acquisitions and partnerships. The key organizational capabilities that enable Boundary Spanning agility include aligned incentives, strong metrics and individual heroics. Interestingly, the key organizational capability for other two categories of agility, the Standardized IT Environment is actually found to be negatively correlated with profitable acquisitions. On the other hand, while the heroic actions of individuals enable boundary spanning agility, it gets highly discouraged for achieving other two categories of agility.
While some organizational characteristics would help for more than one categories of agility, there would involve some trade-offs if an organization attempts to achieve agility in multiple categories.
This kind of understanding of business agility would definitely help in planning for SOA adoption. Let's hope to receive even more understanding about business agility from MIT CISR. We will then be more wise while discussing the need of SOA for achieving business agility.
An article from the Research Briefing 2006 of MIT Sloan CISR would perhaps help us in understanding more about business agility. In this article, authors Jeanne W Ross and Cynthia M Beatch, have defined agility as the set of possible business initiatives a firm can readily implement leveraging pre-determined competencies with managed cost and risk. Based on their research, the authors have identified seven types of business agility, which they have grouped into three categories. These categories and the types are as given below:
- Business Efficiency: Continuous improvement and Scalability
- Market Responsiveness: Product innovation, Process re-engineering and New business model
- Boundary Spanning: Acquisitions and Partnerships
Business Efficiency agility attempts to identify repetitive processes and extract unnecessary cost and time. The continuous improvement agility is more found with commodity businesses such as consumer product manufacturers. Such organizations are required to implement continuous improvement initiatives for accelerating profitability while reducing business risks. Scalability agility is the ability to rapidly scale up and down in response to changing business volumes. This kind of agility is almost must for companies from the Property and Casualty (P&C) Insurance industry as they would experience extraordinary demand for claim processing after natural disasters. The key organizational characteristics that would help to achieve the Business Efficiency agility include the following:
- Standardized IT environment
- Standardized operations processes, systems and data
- Enterprise-wide process design
- Strong metrics and
- Shared services
The speed with which organizations are required to respond to new customer demands and competitive challenges have gained increased importance for market responsiveness agility. Unlike Business Efficiency agility, Market Responsiveness agility disrupts, builds and reuses core capabilities. Interestingly, even if processes must change, companies benefit from developing clearly defined, standard operations processes and related data. Standardized IT Environment also helps in providing the foundation for new processes and interactions. Most notably, matrixed management structure helps companies introducing new capabilities without discarding old capabilities.
Organizations with boundary spanning agility have competencies enabling profitable growth through their acquisitions and partnerships. The key organizational capabilities that enable Boundary Spanning agility include aligned incentives, strong metrics and individual heroics. Interestingly, the key organizational capability for other two categories of agility, the Standardized IT Environment is actually found to be negatively correlated with profitable acquisitions. On the other hand, while the heroic actions of individuals enable boundary spanning agility, it gets highly discouraged for achieving other two categories of agility.
While some organizational characteristics would help for more than one categories of agility, there would involve some trade-offs if an organization attempts to achieve agility in multiple categories.
This kind of understanding of business agility would definitely help in planning for SOA adoption. Let's hope to receive even more understanding about business agility from MIT CISR. We will then be more wise while discussing the need of SOA for achieving business agility.
Checklist for developing a strategy for web services
In his book titled Loosely Coupled, Doug Kaye has offered a checklist for developing a strategy for web services. After going through it, I found it useful as a starting point for making road-map for SOA adoption. This checklist has got more than 80 items grouped into into four categories: Inventory, Project Requirements, Planning and Evangelism. You can find this checklist as a free chapter download (without giving out email address!) from the book web site.
Subscribe to:
Comments (Atom)