Integration Patterns
The patterns contained within this section are primarily logical and SOA specific, and secondarily integration/interoperability specific.
Each pattern solves a specific problem, and in most cases there is no direct duplication within separate patterns that will solve the same problem in all cases. There is always a level of variance.
Each pattern is constructed with a series of logical components. A logical component can be physically implemented with one or more physical components, and can comprise of one or more pieces of technology.
Similarly, the separation between components is a logical one; therefore two logical components can be physically implemented with one or more physical components.
There is therefore another level of re-use beyond the scope of this section that ensures logical patterns are reused and physical patterns of implementation are also likewise reused.
Each pattern considers a standard set of architectural statements and non-functional requirements. Where the pattern deviates from these (usually requiring additional non-functional requirements) then these will be explicitly highlighted within the pattern
The following pattern and sub patterns have been identified:
· Request Reply Method
o Basic Request-Reply (Asynchronous)
o Request-Reply (with ownership transfer in reply)
o Request-Reply (Synchronous consumer)
o Request-Reply (Decoupled reply)
Saturday, 26 September 2009
Wednesday, 2 September 2009
SAVARA : (Architecture: From Art to Engineering)
Software development lifecycle has never been a precise science which is usually driven by ambiguity in requirements, architecture and cascading effect of ambiguity into code. Hence the evidence of large number of IT projects that either fail to deliver or overrun on cost and timescales
Recognizing the need to eliminate ambiguity, we at Cognizant are collaborating with Red Hat to announce a new JBoss Community project called SAVARA that is aimed at solving this perennial problem of ambiguity through simulation and visualization by building upon the SOA Process Governance work that is going on within the JBoss Community (http://www.jboss.org/overlord).
PRESS RELEASE LINK: http://press.redhat.com/2009/09/03/jboss-community-launches-savara-project/
The SAVARA project applies engineering rigour and principles of industrialization to the software development process to improve productivity and quality of architectural artefacts, which result in reducing the cost and time to build business critical systems.
I am Co-chairing this initiative along with Gary Brown (from Redhat)
More details could be found at JBOSS Community Wiki http://www.jboss.org/community/wiki/SAVARA
Recognizing the need to eliminate ambiguity, we at Cognizant are collaborating with Red Hat to announce a new JBoss Community project called SAVARA that is aimed at solving this perennial problem of ambiguity through simulation and visualization by building upon the SOA Process Governance work that is going on within the JBoss Community (http://www.jboss.org/overlord).
PRESS RELEASE LINK: http://press.redhat.com/2009/09/03/jboss-community-launches-savara-project/
The SAVARA project applies engineering rigour and principles of industrialization to the software development process to improve productivity and quality of architectural artefacts, which result in reducing the cost and time to build business critical systems.
I am Co-chairing this initiative along with Gary Brown (from Redhat)
More details could be found at JBOSS Community Wiki http://www.jboss.org/community/wiki/SAVARA
Thursday, 13 August 2009
Architecture and Governance Magazine
My article published in the current issue of Architecture and Governance Magazine
Link: Bhavish Kumar - Enterprise Integration
Link: Bhavish Kumar - Enterprise Integration
Monday, 20 July 2009
Friday, 3 July 2009
TOGAF - EA Practitioner Conference
I am officially running a survey for the Enterprise Architecture Practitioners Confernce (EAPC) working group to clearly identify the potential topics being presentd in future TOGAF Conferences.
Would really appreciate your feedback and support in filling up the survey by following the link below.
TOGAF EAPC TOPIC SURVEY
Would really appreciate your feedback and support in filling up the survey by following the link below.
TOGAF EAPC TOPIC SURVEY
Monday, 22 June 2009
Basic definitions of various architecture roles
Selected as best Answer on Linkedin
“IT architecture has always been compared to an engineering discipline like civil architecture or building systems design. Its only in the last decade or so that IT architecture has introduced a level of formalism and structure From a recruitment consultant's view the following could help
Enterprise Architect : EA refers to the holistic approach and mindset required to address an enterprise in terms of where it is today and where it wants to go in the future, along with the principles, roadmaps and frameworks that help to traverse the path. Enterprise Architect is a seasoned professional who has seen all elements of the value chain including (Business, Functional, Informational and Technology Architectures) and has been involved right from Visioning / Planning to the implementation of such a roadmap for an enterprise / organisation
Solution Architect - An architect who has covered the above mentioned areas with regards to a particular set of tactical OR strategic goals that have been clubbed into a programme. Further a solution architect will ensure that the solution envisioned for a particular enterprise is in adherence to the Enterprise Architecture roadmap and future direction set by the Enteprise Architecture function
Technical Architect - An architect whose focus is key to delivery of the infrastructure / technology elements of a particular programme or set of programmes. A technical architect looks primarily at Non Functional requirements to ensure that solutions delivered will fit with the existing roadmap defined by the Enterprise Architect in terms of adherence to technology principles, guidelines and policies.
Practice Manager - This is a body who has had many years of experience in one / or / more of the above roles at major customers delivering highly complex and risk driven programmes and has finally landed into a role that looks at the following priorities 1. Generation of Intellectual Property (Driving new value propositions to the market) 2. Marketing of these propositions 3. Sales of these propositions 4. Resourcing who can support the delivery of these propositions to the market. A practice on architecture typically would contain a mixture of the above roles you mention. Do let me know if you require further detailed informaiton.”
“IT architecture has always been compared to an engineering discipline like civil architecture or building systems design. Its only in the last decade or so that IT architecture has introduced a level of formalism and structure From a recruitment consultant's view the following could help
Enterprise Architect : EA refers to the holistic approach and mindset required to address an enterprise in terms of where it is today and where it wants to go in the future, along with the principles, roadmaps and frameworks that help to traverse the path. Enterprise Architect is a seasoned professional who has seen all elements of the value chain including (Business, Functional, Informational and Technology Architectures) and has been involved right from Visioning / Planning to the implementation of such a roadmap for an enterprise / organisation
Solution Architect - An architect who has covered the above mentioned areas with regards to a particular set of tactical OR strategic goals that have been clubbed into a programme. Further a solution architect will ensure that the solution envisioned for a particular enterprise is in adherence to the Enterprise Architecture roadmap and future direction set by the Enteprise Architecture function
Technical Architect - An architect whose focus is key to delivery of the infrastructure / technology elements of a particular programme or set of programmes. A technical architect looks primarily at Non Functional requirements to ensure that solutions delivered will fit with the existing roadmap defined by the Enterprise Architect in terms of adherence to technology principles, guidelines and policies.
Practice Manager - This is a body who has had many years of experience in one / or / more of the above roles at major customers delivering highly complex and risk driven programmes and has finally landed into a role that looks at the following priorities 1. Generation of Intellectual Property (Driving new value propositions to the market) 2. Marketing of these propositions 3. Sales of these propositions 4. Resourcing who can support the delivery of these propositions to the market. A practice on architecture typically would contain a mixture of the above roles you mention. Do let me know if you require further detailed informaiton.”
Friday, 19 June 2009
Thoughts 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
Design Authority
Attached above is an example Design Authority document flight plan that can be used as a checklist for establishment, mobilisation and execution of a fit for purpose Design Authority in an enterprise
Wednesday, 11 February 2009
Monday, 19 May 2008
Insight : EA and EI
Prologue:
Enterprise Architecture (EA) can mean different things to different people depending upon the role and responsibility of the individual within the organisation and depending upon the context of the organisation (either being a consultancy OR an end user). To many it is a framework, while others view it as a collection of rules, or a methodology for defining and designing infrastructure services. However the common aims are to improve alignment of the IT Infrastructure with business goals and to attempt to bring stability to an ever changing, chaotic and complex situation.
EA provides the essential backbone (framework) or blueprints for the communication, interpretation and implementation of corporate objectives throughout the organisation and enables the evolution of a strongly aligned IT environment. A plausible way of achieving this would be through creation of a number of interconnected architecture views. The various available frameworks (commercial and / or non-commercial) break the definition of Enterprise Architecture into a different number models and artefacts. EA at the most consists of three main elements viz. Business, Information and Operations.
An effective and pragmatic EA relies on having a common platform and systems infrastructure on which to base the organisations products and services. What we see is, an increasing need of convergence of multiple technologies into a platform providing components for building, managing and deploying services. The convergence platform should be centred on loosely-coupled integration at all levels – system, applications, information, processes and people and the ability to quickly reconfigure these elements to react to threats and opportunities in an organisation’s environment.
How do we achieve it?
Well we first look at some guiding principles which are very much like a lighthouse providing necessary direction and steer to the IT transformation ocean liner… and they are:
Security – The delicate balance between acceptable risk and usability. This is becoming one of the main issues that all public and private sector organsiations have to contend with. It is vital that an enterprise’s information is adequately protected and it will become a precondition of doing business in the future, especially with the inextricable move toward e-business and e-government. The pre-requisite is for security architecture to be considered and deployed at an enterprise level rather than a last minute consideration that this area often receives.
Adapatability – This is required to keep pace with the ever-altering internal and external environment organisations find themselves in. Solutions have to be flexible, catering to changes in requirements, procedures, processes and organisation. Flexibility is also important for successful IT projects and to ensure the robustness of IT services. An important facet of architecture must be the use of modularity to enable continual adaptation, to meet changing business needs and allow re-use of software.
Standards – for open interfaces and data models delivered thorough an Enterprise wide Governance framework are crucial if an EA approach is to succeed. The use of standards extends further than just being used for interoperability. Openness is important for protecting IT investments, both in short and long term by shielding against supplier dependency. The move to more componentisation relies on standardisation.
Performance – must be a critical part of the architecture design. As with security it is very costly to add scalability as an afterthought. Systems need to maintain efficiency and service levels regardless of demand. The whole operation is reliant on the performance of the weakest link!. The architecture must support the increase in users, transaction volumes and data capacity and prevention of bottlenecks.
Management – of the complete architecture process is another important factor. The need for such features such as version control, end-to-end visibility, and monitoring become even more critical. The administration focus should be on support on SLAs, policy-based management and supplying a method of measuring effectiveness.
Defining EA:
EA facilitates a top-down , business objectives led approach, building up a coherent set of business, information, organisation and services architectures that provide different views of the organisation, relationships, proceses and data dependent upon the stakeholder requirements.
EA addresses the need to look at external factors such as market intelligence and exterior environmental events, rather than just looking at current portfolio of in-flight projects/ programmes. This enables the Enterprise Architect to strategise, draw synergies and evaluate opportunities and threats presented by these issues and to determine if changes are required to the enterprise blueprint
A services model utilises the logical-level deliverables provided by the other architectures (business and information) , expanding a platform-independent view of the business processes with associated data and presentation requirements, and using this to develop a platform and technology-dependent model, taking “cognisance” of technologies and utilising a services platform with common components and services. Approaches gaining significant traction in this area of SOA are enterprise class communications backbone like ESB, Model Driven Architecture and adoption of frameworks like TOGAF.
What are customers talking about?:
Enterprise Architecture:
· A number of organisations have implemented an EA. Approaches vary: it can be top down or bottom up
· An EA model can have four levels: Business Architecture, Information Architecture, Applications & Systems Architecture, Technical Architecture
· It is important to have a common vision of where the business is going: this greatly influences application and hardware strategy.
· Key: model the business based on its services: processes can then be modelled within this
· Use templates for EA. Aim for reusability. Identify interdependencies
· Basic tools such as Visio plus Word, or Visio plus Office are commonly used (about half of delegate
· organisations only use these)
· EA is the technique for communicating with the business: methodologies and tools help this
· Tools can be used to document applications and business processes (not necessarily in one tool)
· Important: Consider how the information from the tool will be used to ensure it is fit for its purposes and aids communication
Plans:
− The business strategy translates into the IT strategy.
− Have a planning period covering three years
− Review and update the plan regularly
− Have a decommissioning plan
− Expose projects at an early stage.
· Build governance from the board down. A strong CIO is needed to get support from the business
· Identify the IT elements of business budgets and aggregate them: this shows a total cost of IT
· Have some form of EA Policing / Auditing / Review. Always review pilots
· Achieving control: a lot can be achieved by making the adoption of governance part of personal appraisal objectives.
Enterprise Integration:
Increase the access to and ability to change the Application Services (based upon business need):
− Open published interface standards including XML data formats, Web Services, JMS, FTP and HTTP. Further WSDL and W3C Schemas as service definition” language, and SOAP as the “messaging protocol language”.
− The capability to selectively store message data in an external data store as it traverses the middleware
− Reduced impact of changes to IT Business services to the business
Improve the availability and reliability of the Application Services
− Access to additional (existing) services.
− Generic high availability interconnects facility between all supported system components
− Reduced technical risk of supporting IT Business services
− Load Balancing , fault tolerance and automatic scale up through configuration provisioning
What to consider when focussing on enterprise integration?:(See table)
Enterprise Architecture (EA) can mean different things to different people depending upon the role and responsibility of the individual within the organisation and depending upon the context of the organisation (either being a consultancy OR an end user). To many it is a framework, while others view it as a collection of rules, or a methodology for defining and designing infrastructure services. However the common aims are to improve alignment of the IT Infrastructure with business goals and to attempt to bring stability to an ever changing, chaotic and complex situation.
EA provides the essential backbone (framework) or blueprints for the communication, interpretation and implementation of corporate objectives throughout the organisation and enables the evolution of a strongly aligned IT environment. A plausible way of achieving this would be through creation of a number of interconnected architecture views. The various available frameworks (commercial and / or non-commercial) break the definition of Enterprise Architecture into a different number models and artefacts. EA at the most consists of three main elements viz. Business, Information and Operations.
An effective and pragmatic EA relies on having a common platform and systems infrastructure on which to base the organisations products and services. What we see is, an increasing need of convergence of multiple technologies into a platform providing components for building, managing and deploying services. The convergence platform should be centred on loosely-coupled integration at all levels – system, applications, information, processes and people and the ability to quickly reconfigure these elements to react to threats and opportunities in an organisation’s environment.
How do we achieve it?
Well we first look at some guiding principles which are very much like a lighthouse providing necessary direction and steer to the IT transformation ocean liner… and they are:
Security – The delicate balance between acceptable risk and usability. This is becoming one of the main issues that all public and private sector organsiations have to contend with. It is vital that an enterprise’s information is adequately protected and it will become a precondition of doing business in the future, especially with the inextricable move toward e-business and e-government. The pre-requisite is for security architecture to be considered and deployed at an enterprise level rather than a last minute consideration that this area often receives.
Adapatability – This is required to keep pace with the ever-altering internal and external environment organisations find themselves in. Solutions have to be flexible, catering to changes in requirements, procedures, processes and organisation. Flexibility is also important for successful IT projects and to ensure the robustness of IT services. An important facet of architecture must be the use of modularity to enable continual adaptation, to meet changing business needs and allow re-use of software.
Standards – for open interfaces and data models delivered thorough an Enterprise wide Governance framework are crucial if an EA approach is to succeed. The use of standards extends further than just being used for interoperability. Openness is important for protecting IT investments, both in short and long term by shielding against supplier dependency. The move to more componentisation relies on standardisation.
Performance – must be a critical part of the architecture design. As with security it is very costly to add scalability as an afterthought. Systems need to maintain efficiency and service levels regardless of demand. The whole operation is reliant on the performance of the weakest link!. The architecture must support the increase in users, transaction volumes and data capacity and prevention of bottlenecks.
Management – of the complete architecture process is another important factor. The need for such features such as version control, end-to-end visibility, and monitoring become even more critical. The administration focus should be on support on SLAs, policy-based management and supplying a method of measuring effectiveness.
Defining EA:
EA facilitates a top-down , business objectives led approach, building up a coherent set of business, information, organisation and services architectures that provide different views of the organisation, relationships, proceses and data dependent upon the stakeholder requirements.
EA addresses the need to look at external factors such as market intelligence and exterior environmental events, rather than just looking at current portfolio of in-flight projects/ programmes. This enables the Enterprise Architect to strategise, draw synergies and evaluate opportunities and threats presented by these issues and to determine if changes are required to the enterprise blueprint
A services model utilises the logical-level deliverables provided by the other architectures (business and information) , expanding a platform-independent view of the business processes with associated data and presentation requirements, and using this to develop a platform and technology-dependent model, taking “cognisance” of technologies and utilising a services platform with common components and services. Approaches gaining significant traction in this area of SOA are enterprise class communications backbone like ESB, Model Driven Architecture and adoption of frameworks like TOGAF.
What are customers talking about?:
Enterprise Architecture:
· A number of organisations have implemented an EA. Approaches vary: it can be top down or bottom up
· An EA model can have four levels: Business Architecture, Information Architecture, Applications & Systems Architecture, Technical Architecture
· It is important to have a common vision of where the business is going: this greatly influences application and hardware strategy.
· Key: model the business based on its services: processes can then be modelled within this
· Use templates for EA. Aim for reusability. Identify interdependencies
· Basic tools such as Visio plus Word, or Visio plus Office are commonly used (about half of delegate
· organisations only use these)
· EA is the technique for communicating with the business: methodologies and tools help this
· Tools can be used to document applications and business processes (not necessarily in one tool)
· Important: Consider how the information from the tool will be used to ensure it is fit for its purposes and aids communication
Plans:
− The business strategy translates into the IT strategy.
− Have a planning period covering three years
− Review and update the plan regularly
− Have a decommissioning plan
− Expose projects at an early stage.
· Build governance from the board down. A strong CIO is needed to get support from the business
· Identify the IT elements of business budgets and aggregate them: this shows a total cost of IT
· Have some form of EA Policing / Auditing / Review. Always review pilots
· Achieving control: a lot can be achieved by making the adoption of governance part of personal appraisal objectives.
Enterprise Integration:
Increase the access to and ability to change the Application Services (based upon business need):
− Open published interface standards including XML data formats, Web Services, JMS, FTP and HTTP. Further WSDL and W3C Schemas as service definition” language, and SOAP as the “messaging protocol language”.
− The capability to selectively store message data in an external data store as it traverses the middleware
− Reduced impact of changes to IT Business services to the business
Improve the availability and reliability of the Application Services
− Access to additional (existing) services.
− Generic high availability interconnects facility between all supported system components
− Reduced technical risk of supporting IT Business services
− Load Balancing , fault tolerance and automatic scale up through configuration provisioning
What to consider when focussing on enterprise integration?:(See table)
Cognizant Offerings in this space:
Enterprise Architecture Maturity Assessment - An exercise that involves interviewing and work-shopping with key individuals of the organisation usually at the CXO level to enable addressing immediate needs and setting the direction for the “internal” enterprise (application, programme, organisation - portfolios) and for the “external” enterprise (partners, suppliers, sourcing strategies, selling strategies and most importantly customer retention and growth)
Solution Envisioning – A technique that aims to align organisational stakeholders to business opportunities / challenges through a rapid, high impact and workshop enabled process. This alignment also takes into consideration the core elements or requirements of a solution that addresses this issue or opportunity, and a credible delivery plan. This approach can further be used to capture detailed requirements and to help with tactical and strategic decision making
Thought Leadership and Innovation around SOA – through a robust framework based upon the integration of Programme Management (MSP) and Enterprise architecture methods (TOGAF), EAI COE offerings around specific technologies and further through active participation of standards bodies like HL7 , W3C on Choreography to name a few.
Epilogue:
This paper deals with some of the basics around why organisations are giving a serious thought to Enterprise Architecture and how these considerations play a major role in linking to initiatives like Enterprise Integration.
While it is important to focus on immediate programmes at hand – it is becoming increasingly imperative to also take a step back and view the enterprise from a “aircraft pilot’s viewpoint” to enable stronger linkage of IT initiatives to Business goals, strategies and measures.
Enterprise Integration through traditional EAI methods need to focus on distributed / federated architectures that span multiple geographies and disparate business processes.
A clear view on the definitions, policies and standards for EA and requirements for EI will help the architect on the ground to safely steer this ship to the target destination.
Subscribe to:
Posts (Atom)
