Friday, 7 September 2012
Monday, 27 August 2012
Should I be in the Cloud? What if it Rains?
Extending SOA Governance as a means to addressing Cloud Governance and Standards.
A published perspective on Cloud Governance
A published perspective on Cloud Governance
Wednesday, 9 December 2009
Basics on SOA
The fundamental goal of Web Services and SOA is to improve ROI and TCO over traditionally implemented accidental architecture through point to point interfaces. However, the use of Web Services doesn't guarantee results. There are a number of challenges, many of which are organizational and not strictly technical, that needs to be addressed proactively to achieve measurable benefit.
Narrowing down the set of acceptable ways to use standards from all the available options needs to be checked with policies and procedures. Of course, many of these policies and procedures will naturally need to change over time as regulatory or other compliance requirements change, so when thinking about TCO we need to factor in the inevitable cost of change.
A second challenge is determining who pays for a service shared by many applications. With traditional line of business applications, figuring out who pays is easy - since one team owns everything. For a shared service, ideally each line of business should pay proportional to their use. Those who use it most should pay the most. Essentially this is a transfer-pricing model. It is important to consider how to track usage by each line of business accurately - if you can't measure usage, you can't charge for it!
A third challenge is ensuring that service levels are met. To end users, the customers of the IT infrastructure, the order management application is still the order management application whether it's built as a monolith or it leverages shared services. In either case it must meet the same expectations of performance, availability and functionality. Conversely, if the same user uses two different applications, he may have different expectations of each - even if both applications leverage the same set of shared services.
Let's look at some of the critical success factors (CSFs) and key performance indicators (KPIs) that organisations need to look at when adopting SOA (see diagram below)
While the core Web Services standards successfully address the mechanics of letting applications to talk to one another, successful SOA implementations through delivery of technologies like Integration Buses mean addressing the challenges that lie beyond the pure mechanics of communication. The complexities are numerous: stakeholders with different agendas, policies with cross-functional implications, service levels that must be maintained at all costs, complex interrelationships between services and no lines painted on the data centre floor to connect any of the dots.
Left to grow on its own, a network of Web Services will quickly degenerate into a tangled spaghetti of brittle, single-use integrations and fail to achieve the economies of scale or the cost and flexibility benefits of SOA.
These challenges call for a new breed of solution - SOA Command and Control - that addresses the various technical, business, and organizational requirements and unites all pertinent knowledge in the SOA into a form that's understandable and actionable.
There are five key imperatives of SOA Command and Control: Align, comply, observe, respond, optimize. These five imperatives encapsulate the required, and the associated value, of SOA Command and Control.
Align
IT is successful only if the business is successful, so IT must always be aligned with the business. SOA Command and Control must allow to measure SOA activity against business objectives to understand its current impact on the business, to determine how it's trending, and to predict where it will go in future.
Comply
True SOA Command and Control empowers stakeholders to move from a passive role to an active role of driving policy changes immediately and automatically across the organization. In addition, stakeholders gain visibility as to where and when the policies and procedures are being applied and/or violated.
Observe
By definition, SOA Command and Control provides both detailed and at-a-glance visibility into the inner workings of your SOA at any point in time - automatically, without expensive, time-consuming manual configuration. This facility lets us understand SOA-wide patterns and trends that would never be uncovered with solutions that provide simple statistics and only threshold, rule-based or predictive alerting.
Respond
Root cause analysis (RCA) is important in an SOA because symptoms rarely appear at the location of the root cause - and the root cause may be a service owned by a different group. With SOA Command and Control allow us to accurately and automatically determine the root cause of problems, without expensive, time-consuming manual configuration of rules or relationships. And, once the root cause is determined, the business process can respond in one of many different ways such as notifying administrators, black-listing users, rolling back service changes, rationing capacity, or modifying documents in transit. These responses can be triggered manually, fully automated or even manually overridden when automated responses don't produce the desired result.
Optimize
As with any IT infrastructure, services have a finite capacity to process consumer requests. Determining the capacity requirements of services is especially complicated because each consumer has a different pattern to use with different kinds of requests, and different peak usage periods. And, as new consumers come online, they consume capacity from the service and potentially affect the service level of everybody else. SOA Command and Control lets the business both proactively and reactively optimize the allocation of scarce service resources.
With an effective SOA Command and Control infrastructure, policies can not only be defined once, centrally, but also automatically enforced in the fabric of the network itself. The capabilities of an effective SOA Command and Control platform lets organizations bypass the knowledge gap and successfully achieve the economies of scale as well as the critical cost, time and flexibility benefits of SOA.
With effect to this need, typical organisations intend to leverage the power of standards based, metric driven SOA by implementing the ESB product suites for application integration using a phased approach.
Reference: Enterprise SOA
SOA GOVERNANCE
This is a business issue, as much as an architectural decision.
Requires understanding, motivation, commitment, leadership, and co-operation.
Let's start with what do I mean by IT Governance:
Governance is the harvesting, control and management of key assets owned by an organisation in order to promote and enforce their use for maximum business benefit
What do I then mean by SOA Governance:
An agile and efficient decision and accountability framework to effectively enable and assist in realizing the benefits of Service Orientation
What are the general aims of SOA Governance:
Business Services and Services Infrastructure Layer are key business assets and should be governed as such in line with Enterprise Architecture.
Achieve standardisation of data formats and structures across distributed business services ( split by organisational and geographical boundaries)
Achieve a shared services infrastructure (internal and external) at BSkyB through employing control and due diligence
Align Governance as far as possible to BAU policies and procedures
You might want to pause and think through some of these questions:
The governance model above gives you a clear separation of concerns and the granularity of how a business service is realised in terms of its components focussing on information flow through information architecture that is further supported by technical services and data
What should you typically consider when establishing SOA Governance?
Thinking of SOA Governance as a thinly layered model helps to clearly articulate the vision and the deliverbales and ownership of actions thereby leading to helping to build the justification case/ business case with tangible benefits identified at each layer.
People within the SOA Governance Model must be empowered to make and enforce decisions
Each enterprise will have differing structure requirements and should transcend the organization chart
SOA Board and SOA Compliance Team may have global, regional or business line scope
Pitfalls of SOA Governance
Cultural barriers
Narrowing down the set of acceptable ways to use standards from all the available options needs to be checked with policies and procedures. Of course, many of these policies and procedures will naturally need to change over time as regulatory or other compliance requirements change, so when thinking about TCO we need to factor in the inevitable cost of change.
A second challenge is determining who pays for a service shared by many applications. With traditional line of business applications, figuring out who pays is easy - since one team owns everything. For a shared service, ideally each line of business should pay proportional to their use. Those who use it most should pay the most. Essentially this is a transfer-pricing model. It is important to consider how to track usage by each line of business accurately - if you can't measure usage, you can't charge for it!
A third challenge is ensuring that service levels are met. To end users, the customers of the IT infrastructure, the order management application is still the order management application whether it's built as a monolith or it leverages shared services. In either case it must meet the same expectations of performance, availability and functionality. Conversely, if the same user uses two different applications, he may have different expectations of each - even if both applications leverage the same set of shared services.
Let's look at some of the critical success factors (CSFs) and key performance indicators (KPIs) that organisations need to look at when adopting SOA (see diagram below)
While the core Web Services standards successfully address the mechanics of letting applications to talk to one another, successful SOA implementations through delivery of technologies like Integration Buses mean addressing the challenges that lie beyond the pure mechanics of communication. The complexities are numerous: stakeholders with different agendas, policies with cross-functional implications, service levels that must be maintained at all costs, complex interrelationships between services and no lines painted on the data centre floor to connect any of the dots.
Left to grow on its own, a network of Web Services will quickly degenerate into a tangled spaghetti of brittle, single-use integrations and fail to achieve the economies of scale or the cost and flexibility benefits of SOA.
These challenges call for a new breed of solution - SOA Command and Control - that addresses the various technical, business, and organizational requirements and unites all pertinent knowledge in the SOA into a form that's understandable and actionable.
There are five key imperatives of SOA Command and Control: Align, comply, observe, respond, optimize. These five imperatives encapsulate the required, and the associated value, of SOA Command and Control.
Align
IT is successful only if the business is successful, so IT must always be aligned with the business. SOA Command and Control must allow to measure SOA activity against business objectives to understand its current impact on the business, to determine how it's trending, and to predict where it will go in future.
Comply
True SOA Command and Control empowers stakeholders to move from a passive role to an active role of driving policy changes immediately and automatically across the organization. In addition, stakeholders gain visibility as to where and when the policies and procedures are being applied and/or violated.
Observe
By definition, SOA Command and Control provides both detailed and at-a-glance visibility into the inner workings of your SOA at any point in time - automatically, without expensive, time-consuming manual configuration. This facility lets us understand SOA-wide patterns and trends that would never be uncovered with solutions that provide simple statistics and only threshold, rule-based or predictive alerting.
Respond
Root cause analysis (RCA) is important in an SOA because symptoms rarely appear at the location of the root cause - and the root cause may be a service owned by a different group. With SOA Command and Control allow us to accurately and automatically determine the root cause of problems, without expensive, time-consuming manual configuration of rules or relationships. And, once the root cause is determined, the business process can respond in one of many different ways such as notifying administrators, black-listing users, rolling back service changes, rationing capacity, or modifying documents in transit. These responses can be triggered manually, fully automated or even manually overridden when automated responses don't produce the desired result.
Optimize
As with any IT infrastructure, services have a finite capacity to process consumer requests. Determining the capacity requirements of services is especially complicated because each consumer has a different pattern to use with different kinds of requests, and different peak usage periods. And, as new consumers come online, they consume capacity from the service and potentially affect the service level of everybody else. SOA Command and Control lets the business both proactively and reactively optimize the allocation of scarce service resources.
With an effective SOA Command and Control infrastructure, policies can not only be defined once, centrally, but also automatically enforced in the fabric of the network itself. The capabilities of an effective SOA Command and Control platform lets organizations bypass the knowledge gap and successfully achieve the economies of scale as well as the critical cost, time and flexibility benefits of SOA.
With effect to this need, typical organisations intend to leverage the power of standards based, metric driven SOA by implementing the ESB product suites for application integration using a phased approach.
Reference: Enterprise SOA
SOA GOVERNANCE
This is a business issue, as much as an architectural decision.
Requires understanding, motivation, commitment, leadership, and co-operation.
Let's start with what do I mean by IT Governance:
Governance is the harvesting, control and management of key assets owned by an organisation in order to promote and enforce their use for maximum business benefit
What do I then mean by SOA Governance:
An agile and efficient decision and accountability framework to effectively enable and assist in realizing the benefits of Service Orientation
What are the general aims of SOA Governance:
Business Services and Services Infrastructure Layer are key business assets and should be governed as such in line with Enterprise Architecture.
Achieve standardisation of data formats and structures across distributed business services ( split by organisational and geographical boundaries)
Achieve a shared services infrastructure (internal and external) at BSkyB through employing control and due diligence
Align Governance as far as possible to BAU policies and procedures
You might want to pause and think through some of these questions:
- How are IT and/or SOA Governance decisions made today?
- What decisions needs to made for your clients to have effective SOA Governance?
- Who should make these SOA Governance decisions?
- How will these SOA Governance decisions be made and monitored?
- What Structures, Process, Communication, Tools should be deployed
- When will these services go live on the bus?
The governance model above gives you a clear separation of concerns and the granularity of how a business service is realised in terms of its components focussing on information flow through information architecture that is further supported by technical services and data
What should you typically consider when establishing SOA Governance?
Thinking of SOA Governance as a thinly layered model helps to clearly articulate the vision and the deliverbales and ownership of actions thereby leading to helping to build the justification case/ business case with tangible benefits identified at each layer.
Each aspect of SOA governance requires defined goals
SOA processes and policies must be defined and documented
SOA processes must have clear accountabilities
Strong support/commitment from senior management is a necessity for SOA governance process to work
All SOA processes should be agile, that facilitates continuous change and feedback
Example SOA Governance Processes could be SOA Investment Approval Process or SOA Compliance / Alignment Process
For effective SOA Governance, it is necessary to have workable organizational structures to control and support all governance activitiesPeople within the SOA Governance Model must be empowered to make and enforce decisions
Each enterprise will have differing structure requirements and should transcend the organization chart
SOA Board and SOA Compliance Team may have global, regional or business line scope
Pitfalls of SOA Governance
Cultural barriers
- Readiness to change
- Ownership of common services
- Change management of services and processes
Business Case
- Business drivers
- Technology enablers
De-risk the future
- Standardisation
- Patterns
- Consolidation
Breadth
90 Degree view vs. 360 Degree view
Subscribe to:
Posts (Atom)