Tuesday, February 20, 2007
SOA Patterns
The study of SOA from a Pattern view can reveal interesting insights not least of which is the fact that it is based on several Patterns that have been around for a long time. According to Miko Matsumura VP of WebMethods, three sets of patterns underlie SOA - the consumer pattern, the provider pattern and governance patterns. consumer patterns of runtime and design governance. Consumer patterns are the simple "give me my stuff" paradigm where the consumer gets a service without worrying about underlying compexities. Provider patterns get a little more complicated - providers may have to do complex processing across different ownership domains , then register5 the service and finally provide the service when requested. Governance patterns are both runtime and design time (validate services before they are registered)
Monday, February 19, 2007
Relationships between SOA and EA
Today, I reviewed some basic concepts of traditional Enterprse Architecture . Also explored the space between and overlaps of traditional EA and SOA. which I believe will help provide bacground context in my exploration of SOA Frameworks.
Thursday, February 15, 2007
CSC's SOA Views
In preparation for my next step - which is to look at some of the leading vendors in the SOA space, I began digging into the "blueprint" - the thing I will be able to map to vendor technologies . This blueprint is CSC's SOA Thought Leaders Technology Architecure Framework.
Wednesday, February 14, 2007
SEI's approach to SOA - contd.
SOA has many promised benefits - Today, I examinde the space where SOA intersects with Legacy Systems, specifically looking into the newer and revised approaches being proposed by SEI to help organizations with legacy systems modernize move to SOA.
Sunday, February 11, 2007
What is and What is not SOA
What is SOA
• This is how Eric Marks and Mike Bell define SOA and Services:
“SOA” is a conceptual business architecture where business functionality,or application logic, is made available to SOA users, or consumers,
as shared, reusable services on an IT network.
“Services” are modules of business or application functionality with exposed interfaces, and are invoked by messages.”
What is NOT SOA
• SOA is not a product.
• SOA is not a solution.
• SOA is not a technology.
• SOA cannot be reduced to vendors’ software products,
• SOA is not a quick fix for the IT
• complexity that has accumulated over 30-plus years.
• SOA does not address every IT challenge today. There are some scenarios when SOA is not appropriate
What is SOA
• SOA is not a silver bullet . It needs careful consideration planning and execution but in the end, if executed correctly WILL deliver compelling business value and benefits to any organizaiton
Elements of SOA
• Conceptual SOA vision
• Services
• Enabling technology
• SOA governance and policies
• SOA metrics
• Organizational and behavioral model
A note on Technology
Even though the Technology gets the most press and it’s a valuable element of SOA it is also perhaps the easier part of an SOA and the other elements should not be forgotten
Why SOA – The Solution
Why SOA – What’s different
Why SOA – What’s different
Why SOA – What’s it trying to solve
Why SOA – What’s it trying to solve
SOA Benefits for IT
SOA Benefits for Business
SOA Benefits for Business
Busienss can launch new products and services 30% faster than your competitors because you have reduced or eliminated friction within your enterprise.
Better collaboration between your suppliers and your
design engineers as well as better collaboration with your channel partners.
• This is how Eric Marks and Mike Bell define SOA and Services:
“SOA” is a conceptual business architecture where business functionality,or application logic, is made available to SOA users, or consumers,
as shared, reusable services on an IT network.
“Services” are modules of business or application functionality with exposed interfaces, and are invoked by messages.”
What is NOT SOA
• SOA is not a product.
• SOA is not a solution.
• SOA is not a technology.
• SOA cannot be reduced to vendors’ software products,
• SOA is not a quick fix for the IT
• complexity that has accumulated over 30-plus years.
• SOA does not address every IT challenge today. There are some scenarios when SOA is not appropriate
What is SOA
• SOA is not a silver bullet . It needs careful consideration planning and execution but in the end, if executed correctly WILL deliver compelling business value and benefits to any organizaiton
Elements of SOA
• Conceptual SOA vision
• Services
• Enabling technology
• SOA governance and policies
• SOA metrics
• Organizational and behavioral model
A note on Technology
Even though the Technology gets the most press and it’s a valuable element of SOA it is also perhaps the easier part of an SOA and the other elements should not be forgotten
Why SOA – The Solution
Why SOA – What’s different
Why SOA – What’s different
Why SOA – What’s it trying to solve
Why SOA – What’s it trying to solve
SOA Benefits for IT
SOA Benefits for Business
SOA Benefits for Business
Busienss can launch new products and services 30% faster than your competitors because you have reduced or eliminated friction within your enterprise.
Better collaboration between your suppliers and your
design engineers as well as better collaboration with your channel partners.
Friday, February 9, 2007
SOA Governance
Here's a 5 minute "essentials of SOA Governance" capsule extracted from my couple of hours worth of digging -
SOA Governance has two components . It controls how Services are:
(a) Designed & Developed ( Development Governance)
(b) Deployed and Operated (Runtime Governance)
(a) Development Governance - Use Registries and Repositories to govern development. Registries (for example UDDI) can help re-use of service - a directory of what's available and how to use/re-use it - Contains information about the service, its interface, versioning and security contracts. Because of its use of standards - allows interoperability and true discovery & re-use. Repositories contain all the info needed to implement the service - the implementation code, configuraiton, dependencies and infrastructue specific deployment profiles.
(b) Runtime Governance - Ensures that your SOA is operating smoothly and delivering the value that you think it should be . Ensures that you have consistent policy Management (i.e. Security, Logging , Auditng, SLA ). Uses standards like WS-Policy, WS-Security, WS-Reliability.
Service Policies can be separated from development. Developers can focus on developing services to meet business needs and then at the time of deployment the policy makers can define the policies.
SOA Governance has two components . It controls how Services are:
(a) Designed & Developed ( Development Governance)
(b) Deployed and Operated (Runtime Governance)
(a) Development Governance - Use Registries and Repositories to govern development. Registries (for example UDDI) can help re-use of service - a directory of what's available and how to use/re-use it - Contains information about the service, its interface, versioning and security contracts. Because of its use of standards - allows interoperability and true discovery & re-use. Repositories contain all the info needed to implement the service - the implementation code, configuraiton, dependencies and infrastructue specific deployment profiles.
(b) Runtime Governance - Ensures that your SOA is operating smoothly and delivering the value that you think it should be . Ensures that you have consistent policy Management (i.e. Security, Logging , Auditng, SLA ). Uses standards like WS-Policy, WS-Security, WS-Reliability.
Service Policies can be separated from development. Developers can focus on developing services to meet business needs and then at the time of deployment the policy makers can define the policies.
Wednesday, February 7, 2007
Service Design
Continued Review of Eric Marks and Mike Bells work . Focused on Service Design and Realization.
Five Main Steps:
1.Examine the state of business services- composition, business processes and associations.
2.Design business services granularity maps. Rank and position services on a granularity scale
3.Build demarcation maps. Find business commonalities and discover business service associations and affinities.
4. Apply design operations on the services
5. Realize and expose physical solution services.
I find their dual approach of "Bottom-Up" and "Top-Down" compelling .
Bottom up approach consists of six steps:
1. Study business problems / concerns.
2. Analyze business requirements / processes.
3. Construct granular entities based on software library design
4. Establish source code modules which are founded on business context
5. Design and construct software components.
6. Group components into physical solution services.
Both are needed.
Top Down ignores the technology constratints
Bottom up lacks conceptual and analytical approach
Used in combination – a very powerful toolset
Five Main Steps:
1.Examine the state of business services- composition, business processes and associations.
2.Design business services granularity maps. Rank and position services on a granularity scale
3.Build demarcation maps. Find business commonalities and discover business service associations and affinities.
4. Apply design operations on the services
5. Realize and expose physical solution services.
I find their dual approach of "Bottom-Up" and "Top-Down" compelling .
Bottom up approach consists of six steps:
1. Study business problems / concerns.
2. Analyze business requirements / processes.
3. Construct granular entities based on software library design
4. Establish source code modules which are founded on business context
5. Design and construct software components.
6. Group components into physical solution services.
Both are needed.
Top Down ignores the technology constratints
Bottom up lacks conceptual and analytical approach
Used in combination – a very powerful toolset
Monday, February 5, 2007
Service Analysis Design and Modelling
Continued Review of Eric Marks book . Focused on Service Analysis Design and modelling.
Service Analysis and Design
• Addresses
– consolidation
– decomposition
– reuse
– Simplification
– refactoring of legacy assets
As dictated by organizational imperatives
Service Granularity Analysis
Service Granularity can be determined by :
• Encapsulated business functionality
• Conceptual value and abstraction level
• Scope of business processes they represent or affect.
Service Granularity
• Coarse Grained - Larger subset of business functionality , more function points , multiple business operations
• Fine Grained – Smaller part of problem domain, usually handles a single business operation, or one step of the business process and only a few function points
Service Granularity
• Not set in stone. Can evolve and refine as we move from Identification to Analysis to Design.
Service Granularity
• Not set in stone. Can evolve and refine as we move from Identification to Analysis to Design.
• Iterative process leading to a “Service Granularity Map”
Best Practices for operations
• Decomposition should be performed on medium- to coarse-grain services
• Unification operations should be performed on fine- to medium-grained services.
• Subtraction operations - all granularity
• Subset operations fine- and mediumgrained
• Intersection operations can yield best results when they are applied to medium- and coarse-grained services.
Service Design
• Takes as input the set of final Candidate Services , prioritized according to business needs and with high level granularity, and converts them to Physical Solution Services
• This phase examines conceptual, logical, and physical compositions of services, examine their encapsulated business processes, and facilitate
establishing reliable and reusable physical services.
Service Analysis and Design
• Addresses
– consolidation
– decomposition
– reuse
– Simplification
– refactoring of legacy assets
As dictated by organizational imperatives
Service Granularity Analysis
Service Granularity can be determined by :
• Encapsulated business functionality
• Conceptual value and abstraction level
• Scope of business processes they represent or affect.
Service Granularity
• Coarse Grained - Larger subset of business functionality , more function points , multiple business operations
• Fine Grained – Smaller part of problem domain, usually handles a single business operation, or one step of the business process and only a few function points
Service Granularity
• Not set in stone. Can evolve and refine as we move from Identification to Analysis to Design.
Service Granularity
• Not set in stone. Can evolve and refine as we move from Identification to Analysis to Design.
• Iterative process leading to a “Service Granularity Map”
Best Practices for operations
• Decomposition should be performed on medium- to coarse-grain services
• Unification operations should be performed on fine- to medium-grained services.
• Subtraction operations - all granularity
• Subset operations fine- and mediumgrained
• Intersection operations can yield best results when they are applied to medium- and coarse-grained services.
Service Design
• Takes as input the set of final Candidate Services , prioritized according to business needs and with high level granularity, and converts them to Physical Solution Services
• This phase examines conceptual, logical, and physical compositions of services, examine their encapsulated business processes, and facilitate
establishing reliable and reusable physical services.
Monday, January 22, 2007
Service Identfication
Continuted reserach on Services Identificaiton. In particular Eric Marks book had some interesting insights into Services Identificaiton. Here are some notes and observations :
• Service Identification , Analysis and Design is poorly understood and goes to the heart of a successful SOA
Questions which need Answers…
• What are Services in my project and How do we identify Business Services in our environment?
• Which Services do we start with?
• How do we model and implement SOA Services that are optimal for our business?
• How do we determine Service Granularity?
• How do we determine Service Re-use?
• How did we prioritize Services – determining which ones are more immediately critical to business success?
• How to analyze and design services?
• Before Service Identification can begin, we must go through SOA Business Modeling and Value Analysis Process. These will help to focus the initial identification of Services.
Candidate Business Services
• Top Down and Bottom Up Iterations will eventually identify the core services of an SOA.
• This is called a “Services Driven SOA” – where the Services Identification process will drive everything else : The Technology , Governance Model and Metrics.
Candidate Business Services
Example of Candidate Business Services
Candidate Service Validation
Business Impact Analysis
• Business Value - Does the service have business value?
• ROI - Does it offer cost savings, revenue growth, productivity, customer satisfaction,
• Re-usability - Is it reusable within and across business or process domains?Are those domains important to business? What are the consumption patterns for the service candidate?
• Business Scalability - Does the service address current and future business needs?
• Agility – What are the agility needs of the business ?
Service Feasibility
Technical Feasibility
Business Services Roadmap
After completing the Candidate Services Analysis we can create a Business Services Roadmap - This is a prioritized sequence of services based on their value to the organization
Candidate Service Identificaiton
• The following are six possible ways to identify candidate business services
• 1. Business process analysis
• 2. Core entity analysis
• 3. Opportunistically via budgeted initiatives
• 4. Business or domain expertise
• 5. Preexisting services
• 6. Existing business applications
1. Business process analysis
• Suited to organizations which have completed and maintained detailed process analysis of all major business and process domaons. The high level business value analysis done prior to service identification will help to drive this process of identifying the candidate business services from within the process domain.
1. Business process analysis
1. Perform a high level value chain analysis of your organization.
2. Develop a high-level process map of your enterprise.
3. From this process map, identify candidate business services that relate to these major business processes.
4. Based on these candidate business services, either:
prioritize these services first before continuing on to services modeling; OR Begin modeling for all of these services at once.NOW WE CAN START DESIGN ACTIVITY. (Having a process map jump starts the analysis part of the Modelling)
Core Entity Analysis
• Data modeling perspective.
• Study Data Models, ER diagrams (typically built in Erwin or a similar tool)
Core Entity Analysis
• Identify all Business Entities
• Identify a subset of important (core) ones
• Core Data Entities are more granular than Business Entities – they can answer questions related to who , when , where , why and how?
• Good point to begin Service Identification
• Not all organizations want to implement Business Process modelling prior to an SOA undertaking (too time consuming and complex). In such cases , core entity analysis provides an expedient starting point
Performing Core Entity Analysis
• Brain-Storimng sessions that answer these questions:
• What are the core business entities?What are the major Business “Nouns” found in these entities?
• What services currently touch these Entities? What are the “Verbs” that act on the nouns?
Example
• Customer is a core business entity
• Add Customer Service is a candidate business service
• Customer Summary Information Service is a candidate business service
3. Opportunistic
• Find already budgeted projects and use them to identify SOA Candidate Services
• Most common . Least Ideal.
• Because as the Service Identificaiton Service unfolds it may become clear that priorities need to change! (Better to let the Business Needs drive the priorotization than the current budget)
4. BUSINESS AND DOMAIN EXPERTISE
• Bring together all key stake holders to identify the business candidates services based on their deep domain knowledge and experience Used in conjunction with Process and/or Core Entity Analysis. While this is not an essential pre-requisite for services modelling it certainly helps to expedite it and make it more successful.
5. Existig Services
• These are essential to consider – both well known ones and “Rogue” ones. Each of these must be listed and identified.
• Rogues must be publicly exposed in a organizaiton registry and made to conform to standard governance practices.
EXISTING BUSINESS APPLICATIONS
Examine the existin applications Suite to identify candidates.
You can either :
Replicate the functionality
Wrap the functionality
Aggregate or decompose the functionality
This will be the most likely largest source for Candidate Services.
Top Down or Bottom Up?
Five Steps to Service Modelling
• Identify Candidate services using techniques described earlier
• (Classify?) services based on business events , entities , processes and org. boundaries (to get a better handle on them?)
• Identify re-use and granularity
• Priorotize Services
• Begin Analysis and Design on services
How to prioritize services
• Services that have clear business value.
• Services support business imperatives, address business hot spots, and map to your SOA drivers.
• The services are reusable by multiple consumer communities —business processes, business units, developers, and analysts.
• The services are achievable in a reasonable time frame as compared to traditional development.(Quick Wins)
• The services align with your long term SOA strategy, goals, and objective
• Service Identification , Analysis and Design is poorly understood and goes to the heart of a successful SOA
Questions which need Answers…
• What are Services in my project and How do we identify Business Services in our environment?
• Which Services do we start with?
• How do we model and implement SOA Services that are optimal for our business?
• How do we determine Service Granularity?
• How do we determine Service Re-use?
• How did we prioritize Services – determining which ones are more immediately critical to business success?
• How to analyze and design services?
• Before Service Identification can begin, we must go through SOA Business Modeling and Value Analysis Process. These will help to focus the initial identification of Services.
Candidate Business Services
• Top Down and Bottom Up Iterations will eventually identify the core services of an SOA.
• This is called a “Services Driven SOA” – where the Services Identification process will drive everything else : The Technology , Governance Model and Metrics.
Candidate Business Services
Example of Candidate Business Services
Candidate Service Validation
Business Impact Analysis
• Business Value - Does the service have business value?
• ROI - Does it offer cost savings, revenue growth, productivity, customer satisfaction,
• Re-usability - Is it reusable within and across business or process domains?Are those domains important to business? What are the consumption patterns for the service candidate?
• Business Scalability - Does the service address current and future business needs?
• Agility – What are the agility needs of the business ?
Service Feasibility
Technical Feasibility
Business Services Roadmap
After completing the Candidate Services Analysis we can create a Business Services Roadmap - This is a prioritized sequence of services based on their value to the organization
Candidate Service Identificaiton
• The following are six possible ways to identify candidate business services
• 1. Business process analysis
• 2. Core entity analysis
• 3. Opportunistically via budgeted initiatives
• 4. Business or domain expertise
• 5. Preexisting services
• 6. Existing business applications
1. Business process analysis
• Suited to organizations which have completed and maintained detailed process analysis of all major business and process domaons. The high level business value analysis done prior to service identification will help to drive this process of identifying the candidate business services from within the process domain.
1. Business process analysis
1. Perform a high level value chain analysis of your organization.
2. Develop a high-level process map of your enterprise.
3. From this process map, identify candidate business services that relate to these major business processes.
4. Based on these candidate business services, either:
prioritize these services first before continuing on to services modeling; OR Begin modeling for all of these services at once.NOW WE CAN START DESIGN ACTIVITY. (Having a process map jump starts the analysis part of the Modelling)
Core Entity Analysis
• Data modeling perspective.
• Study Data Models, ER diagrams (typically built in Erwin or a similar tool)
Core Entity Analysis
• Identify all Business Entities
• Identify a subset of important (core) ones
• Core Data Entities are more granular than Business Entities – they can answer questions related to who , when , where , why and how?
• Good point to begin Service Identification
• Not all organizations want to implement Business Process modelling prior to an SOA undertaking (too time consuming and complex). In such cases , core entity analysis provides an expedient starting point
Performing Core Entity Analysis
• Brain-Storimng sessions that answer these questions:
• What are the core business entities?What are the major Business “Nouns” found in these entities?
• What services currently touch these Entities? What are the “Verbs” that act on the nouns?
Example
• Customer is a core business entity
• Add Customer Service is a candidate business service
• Customer Summary Information Service is a candidate business service
3. Opportunistic
• Find already budgeted projects and use them to identify SOA Candidate Services
• Most common . Least Ideal.
• Because as the Service Identificaiton Service unfolds it may become clear that priorities need to change! (Better to let the Business Needs drive the priorotization than the current budget)
4. BUSINESS AND DOMAIN EXPERTISE
• Bring together all key stake holders to identify the business candidates services based on their deep domain knowledge and experience Used in conjunction with Process and/or Core Entity Analysis. While this is not an essential pre-requisite for services modelling it certainly helps to expedite it and make it more successful.
5. Existig Services
• These are essential to consider – both well known ones and “Rogue” ones. Each of these must be listed and identified.
• Rogues must be publicly exposed in a organizaiton registry and made to conform to standard governance practices.
EXISTING BUSINESS APPLICATIONS
Examine the existin applications Suite to identify candidates.
You can either :
Replicate the functionality
Wrap the functionality
Aggregate or decompose the functionality
This will be the most likely largest source for Candidate Services.
Top Down or Bottom Up?
Five Steps to Service Modelling
• Identify Candidate services using techniques described earlier
• (Classify?) services based on business events , entities , processes and org. boundaries (to get a better handle on them?)
• Identify re-use and granularity
• Priorotize Services
• Begin Analysis and Design on services
How to prioritize services
• Services that have clear business value.
• Services support business imperatives, address business hot spots, and map to your SOA drivers.
• The services are reusable by multiple consumer communities —business processes, business units, developers, and analysts.
• The services are achievable in a reasonable time frame as compared to traditional development.(Quick Wins)
• The services align with your long term SOA strategy, goals, and objective
Monday, January 15, 2007
Update for Week Ending - 1/14
During the past week :
1. I continued review of Eric Marks Book
2. Made contact with SEI to obtain the latestupdated on SMART.
3. Attended the Web-Conference on SOA Governance by BEA/IBM/Mercury and Progress Software.
1. I continued review of Eric Marks Book
2. Made contact with SEI to obtain the latestupdated on SMART.
3. Attended the Web-Conference on SOA Governance by BEA/IBM/Mercury and Progress Software.
Monday, January 8, 2007
SOA Book Review
I'm back - after a few weeks and the Holidays.
I am currently in the midst of reading the book : "SOA: A Planning and Implementation Guide for Business and Technology” by Eric A. Marks and Michael Bell . Touted as one of the current best reads for SOA.
Some of the noteworthy items so far:
The section on Governance is very comprehensive. The authors propose a new a Four-Tiered SOA Governance Model that includes Strategic Governance, SOA Operating Model Governance, SOA Lifecycle Governance and SOA Enabling Tools and Technology.
Good discussion on a key topic for SOA - Services Identification - how to find out which parts of an application to convert to a "Service" , where to begin an SOA ? The authors propose a combination of top-down and bottom-up modelling done iteratively for the best results. They recommend the selection of Candidate Business Services - ideal candidates to begin your SOA implementation with.
I am currently in the midst of reading the book : "SOA: A Planning and Implementation Guide for Business and Technology” by Eric A. Marks and Michael Bell . Touted as one of the current best reads for SOA.
Some of the noteworthy items so far:
The section on Governance is very comprehensive. The authors propose a new a Four-Tiered SOA Governance Model that includes Strategic Governance, SOA Operating Model Governance, SOA Lifecycle Governance and SOA Enabling Tools and Technology.
Good discussion on a key topic for SOA - Services Identification - how to find out which parts of an application to convert to a "Service" , where to begin an SOA ? The authors propose a combination of top-down and bottom-up modelling done iteratively for the best results. They recommend the selection of Candidate Business Services - ideal candidates to begin your SOA implementation with.
Subscribe to:
Posts (Atom)