Aggregated enterprise architecture wisdom
I have written about this before, I suspect. So forgive me if this is another representation of that resource.Hanging out with Nigel Green and John Schlesinger is dangerous, so be warned. There be sacred cows being slaughtered in this post.It all start…
It seems that when thinking about events, we have a tendency to put some of the responsibilities in the wrong place. Of course every time we don’t have a proper separation of responsibilities, we get extra complexity. So in this post I will look at som…
Another day of talking to Nigel Green – thank you Skype! And some thinking around processes and their relationship with events. Again sounds innocent – but it seems as if both of us strongy event-oriented thinkers come to common ground when thinking ab…
Quite often people wonder where a Solution Architect fits within the TOGAF Framework and it is not obvious that there is a single answer. I suggest we look first at a generic profile for a Solution Architect.
Companies such as Oracle, Cisco, SAP and others have roles called Solution Architect but with little apparent agreement to what that role is.
Some commonalities between various skills are:
Building Block – A (potentially re-usable) component of business, IT or architectural capability
o A constituent of the architecture model that describes a single aspect of the overall model
o Describe required capability
o Shape the specification of SBBs
o Represents components that will be used to implement the required capability
o A candidate physical solution for an Architecture Building Block (ABB); e.g., a Commercial Off-The-Shelf (COTS) package that is a component of the Acquirer view of the architecture
All ABBs will be stored in the Architecture Landscape of the Architecture Repository. These ABBs will have different levels of granularity to suit different architectural objectives.
The Architecture Definition Document which describes an architecture will contain all artifacts describing as views the building blocks.
During the Phase E, Opportunities and Solutions, we identify work packages and group them into projects, consolidate the gap analysis results from phases B to D, identify the building blocks to be developed or acquired reusing the existing ones (stored in the Architecture Repository) as much as we can. From there, we identify the SBBs which could potentially address one or more gaps and their associated ABBs. Existing SBBs have obviously also to be considered taking the interoperability requirements and dependencies into consideration.
The Solution Architect has a key role in this phase as (s)he will probably be the best qualified to identify the appropriate SBBs. He or she participates in the definition of any Transition Architectures, identifies potential solutions, and helps to formulate a high-level implementation and migration strategy.
During the Migration Planning phase they also have an important mission to ensure that SBBs are properly designed or that acquired solutions support business requirements. The Solution Architect may work closely with the vendor if a COTS solution is considered. A solution includes the hardware, software, and supporting people and documentation to solve a problem.
“The gaps in the existing enterprise solutions framework need to be identified and the specific Solution Building Blocks (SBBs) required to fill these gaps will be the identified by the solutions architects. These SBBs may have a one-to-one or many-to-one relationship with the projects. The solutions architects need to define exactly how this will be done. There may be other projects working on these same capabilities and the solutions architects need to ensure that they can leverage best value from these investments.”
Source: TOGAF 9 (15.4.1)
When the Implementation Governance phase is started, the Solution Architect will work in partnership with the procurer/acquirer in addition to the development team and/or the vendor. He will ensure that the development will comply with the target architecture.
When the solution building blocks are developed or integrated with other existing solutions, the Solution Architect will be working with the development team. His role will be to contribute to the design, development, integration and testing of the new components. This may be considered as being the Solution Architecture activity.
A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high level business and/or IT system specifications and a portfolio of implementation tasks.
Solution architecture starts with an understanding of the problem, which should be documented in the business scenario, and this is where so many projects fail. Too many people have the idea that solving a problem is all about coding.
The Solution Architect is a member of the Enterprise Architecture team but becomes at a later stage also a member of the Development team. His role is mixed; he is the bridge between concepts and implementation. However, the Solution Architect does not operate at the Strategic Architecture level (at the level of the Enterprise) but mostly at Segment and Capability Architecture levels.
“The Solution Architect has the responsibility for architectural design and documentation
at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the Solution Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing.”
Source TOGAF9 (52.6.3)
There is no mapping for a Solution Architect in the TOGAF Skills Framework, but I would suggest, based on my experience, the following proficiency levels:
TOGAF proficiency levels:
Source TOGAF9 (52.4.4)
This approach is related to the current situation in the market for Solutions Architects, where we see that most of their activities are limited to phases E to G. Another approach would be to consider a Solution Architect being involved in all phases of the TOGAF ADM from phase A and on-wards. A follow-up paper will describe how to address solutions from Phase A , when constraints exist, defining the role and responsibilities of a Solution Architect.
Quite often people wonder where a Solution Architect fits within the TOGAF Framework and it is not obvious that there is a single answer. I suggest we look first at a generic profile for a Solution Architect.
Companies such as Oracle, Cisco, SAP and others have roles called Solution Architect but with little apparent agreement to what that role is.
Some commonalities between various skills are:
Building Block – A (potentially re-usable) component of business, IT or architectural capability
o A constituent of the architecture model that describes a single aspect of the overall model
o Describe required capability
o Shape the specification of SBBs
o Represents components that will be used to implement the required capability
o A candidate physical solution for an Architecture Building Block (ABB); e.g., a Commercial Off-The-Shelf (COTS) package that is a component of the Acquirer view of the architecture
All ABBs will be stored in the Architecture Landscape of the Architecture Repository. These ABBs will have different levels of granularity to suit different architectural objectives.
The Architecture Definition Document which describes an architecture will contain all artifacts describing as views the building blocks.
During the Phase E, Opportunities and Solutions, we identify work packages and group them into projects, consolidate the gap analysis results from phases B to D, identify the building blocks to be developed or acquired reusing the existing ones (stored in the Architecture Repository) as much as we can. From there, we identify the SBBs which could potentially address one or more gaps and their associated ABBs. Existing SBBs have obviously also to be considered taking the interoperability requirements and dependencies into consideration.
The Solution Architect has a key role in this phase as (s)he will probably be the best qualified to identify the appropriate SBBs. He or she participates in the definition of any Transition Architectures, identifies potential solutions, and helps to formulate a high-level implementation and migration strategy.
During the Migration Planning phase they also have an important mission to ensure that SBBs are properly designed or that acquired solutions support business requirements. The Solution Architect may work closely with the vendor if a COTS solution is considered. A solution includes the hardware, software, and supporting people and documentation to solve a problem.
“The gaps in the existing enterprise solutions framework need to be identified and the specific Solution Building Blocks (SBBs) required to fill these gaps will be the identified by the solutions architects. These SBBs may have a one-to-one or many-to-one relationship with the projects. The solutions architects need to define exactly how this will be done. There may be other projects working on these same capabilities and the solutions architects need to ensure that they can leverage best value from these investments.”
Source: TOGAF 9 (15.4.1)
When the Implementation Governance phase is started, the Solution Architect will work in partnership with the procurer/acquirer in addition to the development team and/or the vendor. He will ensure that the development will comply with the target architecture.
When the solution building blocks are developed or integrated with other existing solutions, the Solution Architect will be working with the development team. His role will be to contribute to the design, development, integration and testing of the new components. This may be considered as being the Solution Architecture activity.
A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high level business and/or IT system specifications and a portfolio of implementation tasks.
Solution architecture starts with an understanding of the problem, which should be documented in the business scenario, and this is where so many projects fail. Too many people have the idea that solving a problem is all about coding.
The Solution Architect is a member of the Enterprise Architecture team but becomes at a later stage also a member of the Development team. His role is mixed; he is the bridge between concepts and implementation. However, the Solution Architect does not operate at the Strategic Architecture level (at the level of the Enterprise) but mostly at Segment and Capability Architecture levels.
“The Solution Architect has the responsibility for architectural design and documentation
at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the Solution Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing.”
Source TOGAF9 (52.6.3)
There is no mapping for a Solution Architect in the TOGAF Skills Framework, but I would suggest, based on my experience, the following proficiency levels:
TOGAF proficiency levels:
Source TOGAF9 (52.4.4)
This approach is related to the current situation in the market for Solutions Architects, where we see that most of their activities are limited to phases E to G. Another approach would be to consider a Solution Architect being involved in all phases of the TOGAF ADM from phase A and on-wards. A follow-up paper will describe how to address solutions from Phase A , when constraints exist, defining the role and responsibilities of a Solution Architect.
The thought behind this post comes from the rich pageant of daily life with Madame. Yesterday morning we were discussing when she should visit her mother (a sprightly 96 year old who lives about 1,000 miles from us). So it was a matter of looking for d…
Come join us for Architecture Friday in Antwerp on 26 June about next generation enterprise architecture, as seen by two Australians and a Dane: Peter Bernus (wp) and Pat Turner, and me. If you want to participate, get in touch (you may get a discount code!). Peter Bernus chairs IFIP WG5.12 Architectures for Enterprise Integration,
ITIL V3 is structured in 5 modules, one of them being The Service Design book. This book refers to technology-related activities (requirements engineering; data/information management and application management). It also covers some of the practicalities: functional roles analysis; activity analysis; roles/responsibilities; and even service design and management tools. Service Design processes are important because they provide organizations with information that will affect their decisions on designing solutions for new or changed services-
Service Design has five aspects:
Section 3.6.3 on page 35, provides a specific context for the terms “architecture” and “system” which is well aligned with ISO/IEC 42010:2007 definition used by TOGAF 9.
”Architecture” is defined as:
“The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.”
”System ” in this definition is used in the most general, not necessarily IT, sense:
“A collection of components organized to accomplish a specific function or set of functions.“
”architectural design” as :
“The development and maintenance of IT policies, strategies, architectures, designs, documents, plans and processes for the deployment and subsequent operation and improvement of appropriate IT services and solutions throughout an organization.”
In ITIL V3, IT policies and strategies are defined by senior management during the Service Strategy phase of the service lifecycle. These policies may be also be reused during the Preliminary Phase of TOGAF 9. The Preliminary Phase allows us to establish the business context, customize TOGAF, define architecture principles, and establish the governance structure. Architectural Principles are general rules and guidelines that support the way in which an organization sets about fulfilling its mission. These principles should be the source for the creation of IT policies.
Service Architects and Designers will need to consider several resources such as (budgets, infrastructures, applications, information, and people) and capabilities (management, organization, processes, knowledge, and people) of the organization defined by TOGAF 9. This will have to be coordinated with the business requirements which may have been collected from a Business Scenario (TOGAF). Using inputs from the business and Service Strategy in ITIL V3, the design needs to take into consideration, people, processes, products, and partners. Also designers will have to take into consideration, the vision, mission, goals, and objectives in order to translate them into critical success factors, key performance indicators, metrics and measurements.
Documents in ITIL V3 may be considered as being artifacts in TOGAF 9. Artifacts consist of plans, contracts (Architecture contracts or other forms of contracts), job descriptions, organizational structures, process workflows, procedures, instructions, configuration, diagrams, catalogs, lists, and databases among many other document types.
One of the major difficulties for the designer will be to sort through this documentation and remove that which is obsolete, duplicated, incomplete, or erroneous. TOGAF with its Architecture repository may also help to store documents related to IT Service Management. You may also think of combining a CMDB with an Architecture Repository…but that would be another topic to discuss.
Although plans should be considered as documents, it is important to identify and sift through the myriads of plans that are in use in the organization. Plans may be produced by different lines of business including IT, issued by business planning committees, PMO, etc. Some of the difficulties will include gathering them (business plans, IT plans, operational plans, contingency plans, financial plans.etc.) , making sense of them and more importantly, making sure they are aligned. For these reasons, the TOGAF Migration Planning phase helps to coordinate different business areas and create a common plan.
The term architecture within ITIL V3 may be aligned with the 4 architecture domains from TOGAF:
Some aspects may not be covered by architecture domains such the Environment (heat, ventilation, AC, etc.), or the physical workspace including safety (this would be covered by Security Architecture considered during the ADM phases).
Services would be a combination of the four domains.
The Service Design activities and processes covers:
These processes can be designed when building the Technology Architecture with the Technical Reference Model (TRM).
Page 37 of the Service Design book refers to many documented practices available for designing, deploying, and operating service architecture. It lists Enterprise Architecture frameworks, one of them being TOGAF!
ITIL V3 is structured in 5 modules, one of them being The Service Design book. This book refers to technology-related activities (requirements engineering; data/information management and application management). It also covers some of the practicalities: functional roles analysis; activity analysis; roles/responsibilities; and even service design and management tools. Service Design processes are important because they provide organizations with information that will affect their decisions on designing solutions for new or changed services-
Service Design has five aspects:
Section 3.6.3 on page 35, provides a specific context for the terms “architecture” and “system” which is well aligned with ISO/IEC 42010:2007 definition used by TOGAF 9.
”Architecture” is defined as:
“The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.”
”System ” in this definition is used in the most general, not necessarily IT, sense:
“A collection of components organized to accomplish a specific function or set of functions.“
”architectural design” as :
“The development and maintenance of IT policies, strategies, architectures, designs, documents, plans and processes for the deployment and subsequent operation and improvement of appropriate IT services and solutions throughout an organization.”
In ITIL V3, IT policies and strategies are defined by senior management during the Service Strategy phase of the service lifecycle. These policies may be also be reused during the Preliminary Phase of TOGAF 9. The Preliminary Phase allows us to establish the business context, customize TOGAF, define architecture principles, and establish the governance structure. Architectural Principles are general rules and guidelines that support the way in which an organization sets about fulfilling its mission. These principles should be the source for the creation of IT policies.
Service Architects and Designers will need to consider several resources such as (budgets, infrastructures, applications, information, and people) and capabilities (management, organization, processes, knowledge, and people) of the organization defined by TOGAF 9. This will have to be coordinated with the business requirements which may have been collected from a Business Scenario (TOGAF). Using inputs from the business and Service Strategy in ITIL V3, the design needs to take into consideration, people, processes, products, and partners. Also designers will have to take into consideration, the vision, mission, goals, and objectives in order to translate them into critical success factors, key performance indicators, metrics and measurements.
Documents in ITIL V3 may be considered as being artifacts in TOGAF 9. Artifacts consist of plans, contracts (Architecture contracts or other forms of contracts), job descriptions, organizational structures, process workflows, procedures, instructions, configuration, diagrams, catalogs, lists, and databases among many other document types.
One of the major difficulties for the designer will be to sort through this documentation and remove that which is obsolete, duplicated, incomplete, or erroneous. TOGAF with its Architecture repository may also help to store documents related to IT Service Management. You may also think of combining a CMDB with an Architecture Repository…but that would be another topic to discuss.
Although plans should be considered as documents, it is important to identify and sift through the myriads of plans that are in use in the organization. Plans may be produced by different lines of business including IT, issued by business planning committees, PMO, etc. Some of the difficulties will include gathering them (business plans, IT plans, operational plans, contingency plans, financial plans.etc.) , making sense of them and more importantly, making sure they are aligned. For these reasons, the TOGAF Migration Planning phase helps to coordinate different business areas and create a common plan.
The term architecture within ITIL V3 may be aligned with the 4 architecture domains from TOGAF:
Some aspects may not be covered by architecture domains such the Environment (heat, ventilation, AC, etc.), or the physical workspace including safety (this would be covered by Security Architecture considered during the ADM phases).
Services would be a combination of the four domains.
The Service Design activities and processes covers:
These processes can be designed when building the Technology Architecture with the Technical Reference Model (TRM).
Page 37 of the Service Design book refers to many documented practices available for designing, deploying, and operating service architecture. It lists Enterprise Architecture frameworks, one of them being TOGAF!
This post arises from conversations (over many years) with John Hall, the late Keith Robinson, Bob Brown, Keri Healy, Nigel Green, Richard Veryard and Fred Fickling. It has to do with how we identify things, immutability and most recently REST. So firs…
Quite often as an Enterprise Architects we are asked to show what the deliverables of an Enterprise Architecture program are.
TOGAF provides a methodology for analyzing your specific situation and turning that analysis into deliverables and actionable artifacts. Artifacts may have different shapes as defined in TOGAF 9. They may be: Catalogs, matrices or diagrams. EA artifacts may also help to define a standard set of document types such as education, strategy, decision, policy, standard, guideline, etc. It is also recommended that you set up a simple online discussion thread or wiki for each artifact to solicit feedback from artifact consumers.
If we consider the various architecture domains, they may have different forms.
These are very basic example of what artifacts may look like. They may rapidly be created and are definitely a way to explain to the EA stakeholders how the first deliverables of our baseline architecture looks like.
Other practitioners and researchers often quote my research to highlight enterprise architecture adoption challenges. In my practical work and research, I see EA as a toolbox that embraces, supplements, and extends other disciplines. I think that the jungle of commercial … Continue reading →