This paper cover major dimensions which should be considered for large scale SOA based engagements. It is based on the experience in executing large engagements in the same space and also based on performing architectural reviews of such initiative as part of consulting engagements.
Enterprise Architectural RoadMap-Transition to Target State
It was observed in multiple business transformation engagements, it starts well by starting enterprise architecture definition starting by capturing current state of the architecture and then defining the target states in terms of Business architecture, Information Architecture and Technology Architecture. But in the most of the cases, they have defined the target state which they want to achieve in 3-5 years which is a very long period. In almost majority of the cases, those initiatives failed to meet even 50% of intended objectives. Is that because of the issues with Target State Architecture? In most of the cases where I have involved in the review of such initiatives, it has been observed that it is not target state but failure is due to lack of transition architecture.
It is very important to define transition architecture in terms of Business/Information/Technology Architecture which represents intermediary state between current state and target state. Ideally it should be better to define intermediary state one want to achieve in a year’s time. After the first transition state milestone, team should do review that if they have achieved all objectives of intermediary architecture state and ensure if they are in right track to achieve the target state architecture. Based on the feedback of such iterations, target state should be tweaked. At the same time, minor changes could be made to exploit the opportunities and also handle threats associated with changes in PESTEL world so that they stay relevant in terms of achieving target business objective. At the same time, intermediary state should be defined in a way that business should be able to see visible benefits so that it will keep their interest and continue investing in the long term initiative.
Architecture Principles- Form the basis of the governance
In any major architecture initiative, the definition of the architecture principles should be one of the first activities to be performed. It is key to the success of architecture governance strategy. The architecture principle reflect the consensus across the enterprise and embody the spirit and thinking of the enterprise architecture. As per TOGAF framework, it act as
Principles that govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture
Principles that govern the implementation of the architecture, establishing the first tenets and related guidance for designing and developing information systems
This is extremely important step as it provides guidance and also put constraints on any architectural decisions. It has been observed that most the cases this is one of the neglected activity and if done it is cut and copy paste from enterprise architecture literature or just done for the sake of process compliance. In the worst case, it is also observed that there is total neglect for the same. If there are not commonly accepted architecture principles in place, this will lead to inconsistent decision making and also complete failure of the architecture governance mechanism. So it is imperative to define architecture principle upfront at organizational level in terms of IT Principles which should dictate Architecture Principles. At the same time, care should be taken to have buy- in from all relevant stakeholders before formally adopting the same. If the organization is mature one, there will be already one defined at enterprise level which could be readily leveraged for the same. It has observed that in such organizations, architecture governance mechanism is not just for sake of process compliance but it truly bring business value to the organization.
Architectural Patterns and Practices- Enables in faster adoption with discipline
After the adoption of architecture principles and definition of target and transition state architectures, team will be very clear about where they are headed to. This provides a great opportunity for another level of optimization in large scale IT initiative which may involve execution of multiple projects in parallel by different globally distributed teams. Optimization steps could include following
Form Solution Architecture group which act as an extension of Enterprise Architecture group. It should contain members from globally distributed team. Ideally it would be better to have at-least one from each location so that they could also play the role of local evangelist who could share relevant information and also in forming the consensus with local team.
Identify the common set of architecturally significant requirements for each transition architectural state and also potential ones for target architecture state.
Start defining solution patterns to address those requirements by complying with architecture principles.
This activity will help in bringing the consistency in terms of design choices for addressing similar concerns and also help in reusing IT resources which includes both software & hardware components. This could potentially bring in additional cost savings.
Setting the stage for adoption
In large scale adoption of service orientation, one of the key aspects to consider is the ability to work as a team not within a project team but across the multiple project teams. This is critical for successful delivery of service oriented solutions. So this calls for additional roles that are required for ensuring team work on a larger scale and maintain trust among members of this larger group so that they could rely on each other for successful delivery.
Another important aspect is to ensure that whole team is fully aware of the overall objective of the business program and high level understanding of transition and target state architecture. The appropriate team must have deeper understanding of various elements of these architectural states and also should be well versed with solution patterns, associated best practices and methodologies. At the same time, it is important to adopt common communication framework based on common vocabulary, concepts and methods. The team should be provided appropriate training and followed with internal assessment to measure the understanding. This is not about SOA architecture concepts or service technologies but more about contextually significant ones. This would ensure the common understanding which is very important for team work at such a large scale. At the same time, it is important to have appropriate governance mechanism which ensures that development team follows the solution patterns and adhere to architectural standards. So enforcing discipline in terms of how consistently team applies its knowledge is also key.
Conclusion
This white paper tries to cover set of recommendations which could be considered when you embark on larger IT initiative. As always there is no one right way to address any concern but many ones. Above one is one such way to address common concerns we normally would encounter with such initiatives.
Enterprise Architectural RoadMap-Transition to Target State
It was observed in multiple business transformation engagements, it starts well by starting enterprise architecture definition starting by capturing current state of the architecture and then defining the target states in terms of Business architecture, Information Architecture and Technology Architecture. But in the most of the cases, they have defined the target state which they want to achieve in 3-5 years which is a very long period. In almost majority of the cases, those initiatives failed to meet even 50% of intended objectives. Is that because of the issues with Target State Architecture? In most of the cases where I have involved in the review of such initiatives, it has been observed that it is not target state but failure is due to lack of transition architecture.
It is very important to define transition architecture in terms of Business/Information/Technology Architecture which represents intermediary state between current state and target state. Ideally it should be better to define intermediary state one want to achieve in a year’s time. After the first transition state milestone, team should do review that if they have achieved all objectives of intermediary architecture state and ensure if they are in right track to achieve the target state architecture. Based on the feedback of such iterations, target state should be tweaked. At the same time, minor changes could be made to exploit the opportunities and also handle threats associated with changes in PESTEL world so that they stay relevant in terms of achieving target business objective. At the same time, intermediary state should be defined in a way that business should be able to see visible benefits so that it will keep their interest and continue investing in the long term initiative.
Architecture Principles- Form the basis of the governance
In any major architecture initiative, the definition of the architecture principles should be one of the first activities to be performed. It is key to the success of architecture governance strategy. The architecture principle reflect the consensus across the enterprise and embody the spirit and thinking of the enterprise architecture. As per TOGAF framework, it act as
Principles that govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture
Principles that govern the implementation of the architecture, establishing the first tenets and related guidance for designing and developing information systems
This is extremely important step as it provides guidance and also put constraints on any architectural decisions. It has been observed that most the cases this is one of the neglected activity and if done it is cut and copy paste from enterprise architecture literature or just done for the sake of process compliance. In the worst case, it is also observed that there is total neglect for the same. If there are not commonly accepted architecture principles in place, this will lead to inconsistent decision making and also complete failure of the architecture governance mechanism. So it is imperative to define architecture principle upfront at organizational level in terms of IT Principles which should dictate Architecture Principles. At the same time, care should be taken to have buy- in from all relevant stakeholders before formally adopting the same. If the organization is mature one, there will be already one defined at enterprise level which could be readily leveraged for the same. It has observed that in such organizations, architecture governance mechanism is not just for sake of process compliance but it truly bring business value to the organization.
Architectural Patterns and Practices- Enables in faster adoption with discipline
After the adoption of architecture principles and definition of target and transition state architectures, team will be very clear about where they are headed to. This provides a great opportunity for another level of optimization in large scale IT initiative which may involve execution of multiple projects in parallel by different globally distributed teams. Optimization steps could include following
Form Solution Architecture group which act as an extension of Enterprise Architecture group. It should contain members from globally distributed team. Ideally it would be better to have at-least one from each location so that they could also play the role of local evangelist who could share relevant information and also in forming the consensus with local team.
Identify the common set of architecturally significant requirements for each transition architectural state and also potential ones for target architecture state.
Start defining solution patterns to address those requirements by complying with architecture principles.
This activity will help in bringing the consistency in terms of design choices for addressing similar concerns and also help in reusing IT resources which includes both software & hardware components. This could potentially bring in additional cost savings.
Setting the stage for adoption
In large scale adoption of service orientation, one of the key aspects to consider is the ability to work as a team not within a project team but across the multiple project teams. This is critical for successful delivery of service oriented solutions. So this calls for additional roles that are required for ensuring team work on a larger scale and maintain trust among members of this larger group so that they could rely on each other for successful delivery.
Another important aspect is to ensure that whole team is fully aware of the overall objective of the business program and high level understanding of transition and target state architecture. The appropriate team must have deeper understanding of various elements of these architectural states and also should be well versed with solution patterns, associated best practices and methodologies. At the same time, it is important to adopt common communication framework based on common vocabulary, concepts and methods. The team should be provided appropriate training and followed with internal assessment to measure the understanding. This is not about SOA architecture concepts or service technologies but more about contextually significant ones. This would ensure the common understanding which is very important for team work at such a large scale. At the same time, it is important to have appropriate governance mechanism which ensures that development team follows the solution patterns and adhere to architectural standards. So enforcing discipline in terms of how consistently team applies its knowledge is also key.
Conclusion
This white paper tries to cover set of recommendations which could be considered when you embark on larger IT initiative. As always there is no one right way to address any concern but many ones. Above one is one such way to address common concerns we normally would encounter with such initiatives.
No comments:
Post a Comment