8 years, 8 months ago

Using predictions to think ahead

It’s about this time every year that we begin to be bombarded with the top 10 predictions for just about everything in 2010. About the only thing I believe from the predictions mania is that new technology will take longer to have an impact than we believe and that in many cases we really don’t have a clue just how big the impact will really be.

 

One of the more interesting of this year’s crop of predictions (for me at least) is represented on the map at this link  although you’ll need a big printer to make it readable or a bit of pan and zoom.

 

What I like about this is the sheer scope and scale of the map that allows me to see ideas being grouped together and consider the bigger picture if a set of them do happen around the same time – and what our opportunity might be if we’re ready for the situation.

 

Enterprise Architecture is not just about creating models but also about understanding the potential for change and building the appropriate level of agility into the future architecture to be able to take advantage of it without increasing the cost or risk beyond what could reasonably be expected.

8 years, 8 months ago

Using predictions to think ahead

It’s about this time every year that we begin to be bombarded with the top 10 predictions for just about everything in 2010. About the only thing I believe from the predictions mania is that new technology will take longer to have an impact than we believe and that in many cases we really don’t have a clue just how big the impact will really be.

 

One of the more interesting of this year’s crop of predictions (for me at least) is represented on the map at this link  although you’ll need a big printer to make it readable or a bit of pan and zoom.

 

What I like about this is the sheer scope and scale of the map that allows me to see ideas being grouped together and consider the bigger picture if a set of them do happen around the same time – and what our opportunity might be if we’re ready for the situation.

 

Enterprise Architecture is not just about creating models but also about understanding the potential for change and building the appropriate level of agility into the future architecture to be able to take advantage of it without increasing the cost or risk beyond what could reasonably be expected.

Categories Uncategorized
8 years, 9 months ago

Are you a Business Architect or a Business Analyst?

Enterprise Architecture domains include Business Architecture which is the first architecture domain within TOGAF 9. An Enterprise Architecture program that includes this domain, maps critical business processes to their application, information, and infrastructure components to provide a comprehensive view of the business and IT landscape that enables informed decision-making.

Business Architects are supposed to manage Business Architecture, but who are they, what are their skills? How are they different to a Business Analyst or even a Project Manager?

Business Analysts are on the way to becoming Business Architects. Sometimes called IT Business Analysts, they are not strictly business or IT specialists. They write business cases (with very few technical terms), identify business requirements and often are part of a Development Team.

Based on many job descriptions and my observation below, is a grid of standard skills and responsibilities related to the function of a Business Analyst. In the second column, are the responsibilities also applicable to a Business Architect and in the last column comments on how TOGAF 9 recommend the activities to be addressed.

Expected skills and activitiesBusiness AnalystBusiness ArchitectComments related to TOGAF 9
Is an intermediary between IT and the business users, follows the implementation strategy with respect to getting stakeholder buy-in and support.xxBoth roles require to be positioned between IT and business.
In particular business processes of a line of business.xThe Business Architect considers the organization’s strategy and less focused in a specific line of business.
Acts as catalyst to implement strategic and tactical change for the business.xxThe Business Architect will focus more on strategic changes.
Works with end-user groups to assist with aligning IT to the department’s business goals. Conduct feasibility studies to define the purpose, functions, and overall structure of business processesxxThe Business Architect in TOGAF 9 will use Business Scenario techniques.
May be involved in Business Process Management (BPM).xx
Performs analysis and documents business processes leading to process change and/or system implementation.xxThe Business Architect will model and process the business processes.
Operating as a more-or-less independent group that is focused on delivering BPM servicesxThe Business Architect will be working at a strategic level and will be less focused on the delivery of BPM services.
Does not have an IT background, but had, instead, a background in quality control.xThe Business Architect must have a perfect knowledge of the business.
Translates user requirements into software requirements that IT can then use to develop softwarexA Business Architect would not develop and review design specifications for software application. This would be the role of the Application Architect during Phase C.
Analyze and resolve software errors in a timely and accurate fashionxA Business Architect is not in charge of managing incidents linked to applications. IT operations may escalate this to the Development Team, or the vendor. Once a first level of diagnostic done, it will be transferred to one of the architects depending on the domain (technology, application).
Helps to develop and maintain software to support the business processes. Assist in developing system/application architecture.xThe Business Architect does not contribute to software development. This is done by the Solution Architect.
Leads and validates enterprise system designs across multiple business applications.xThe Business Architect does not lead Application Architecture. This will be done by the Application Architect and potentially the Solution Architect.
Creates and executes test plans to ensure that the functional and business requirements are met by the proposed solutionxThe Business Architect does not contribute to test plans. This is done probably by the Solution Architect.
Documents and defines processes, eliminating activities that don’t add value and straightening out the flow of the activities.xxIn the TOGAF 9 Phase B we would do this by documenting the baseline and target architecture and do a gap analysis, identifying the various business architecture building blocks to be eliminated.
Determining how business policies are implemented in business rules.xxBusiness rules have to be identified and implemented when business processes documented in both baseline and target architecture. Can be done at both strategic and tactical level.
Analyses customer needs and the processes customers go through to interact with an organization are key skills that any business process practitioner needs to be effective.xxBusiness scenarios would be used to identify business requirements.
Creates, manages and maintains an optimum business architecture that includes informational, organizational, process, performance and systems architecture.xThe Business Analyst focus more on projects delivery. The Business Architect is mostly focused on the delivery of the Business Architecture.
Defines, socializes and implements Business Architecture. Reviews roadmap projects for impact and compliance.xBusiness Architecture roadmaps will be delivered from the gap analysis.
Identifies and facilitates cross divisional continuous business improvement initiatives.xThe Business Architect works at a strategic level and focus mostly on Strategic Architecture.
Member of the Architecture Board, composed of representative process owners who approve any cross organizational business process changes.xBusiness Architects should be part of the Architecture Board.
Identifies and maintains an up to date picture of opportunities and risks.xxRisks have to be identified during both the Architecture vision phase and the development of the solution.
Experienced in business/process architecture including broad skills in the area of strategy mapping, business analysis skills, conceptual data and process modeling/design, EA frameworks.xThe Business Architect must have these skills. The Business Analyst may focus on process modeling only.
Strong work experience in Project and Change management.xxBoth roles require these skills.
Proven track record for working effectively with technical and business functions.xThe Business Architect must work with other domain’s architects.

My observations are:

Business Analysts are much closer to IT. They often are assigned to a specific Line of Business, which is close to the Development Team, and are implicated in software development. They may be part of the Development Team or the Project Management Office. The Business Architect reports to managers or senior managers who may be business or IT but are independent of any project. They have a global view on most business and will be responsible for modeling the business as a whole, then working top down to “architect” encompassing end to end business processes. Their role is more horizontal and is considered a neutral voice and because of that will make more critical decisions than a Business Analyst.

Business Analysts document requirements as defined by users during workshops. A Business Architect documents and may contribute to define a business strategy using requirements provided by the users if that strategy is not finalized. The Business Architect must have the ability to think in both a strategic and tactical manner whereas a Business Analyst is normally tactical.

The Business Analyst operates within the confines of a predetermined application and technology architecture. A Business Architect is a part of the decision making process to define the IT architecture (Data, Application and Technology). He will have a strong influence directing information technology to meet business needs, and assist in identifying business inefficiencies and opportunities.

Business Architect must be cognizant of enterprise strategies whereas a Business Analyst is normally concerned with specific projects independent of enterprise strategy.

8 years, 9 months ago

Are you a Business Architect or a Business Analyst?

Enterprise Architecture domains include Business Architecture which is the first architecture domain within TOGAF 9. An Enterprise Architecture program that includes this domain, maps critical business processes to their application, information, and infrastructure components to provide a comprehensive view of the business and IT landscape that enables informed decision-making.

Business Architects are supposed to manage Business Architecture, but who are they, what are their skills? How are they different to a Business Analyst or even a Project Manager?

Business Analysts are on the way to becoming Business Architects. Sometimes called IT Business Analysts, they are not strictly business or IT specialists. They write business cases (with very few technical terms), identify business requirements and often are part of a Development Team.

Based on many job descriptions and my observation below, is a grid of standard skills and responsibilities related to the function of a Business Analyst. In the second column, are the responsibilities also applicable to a Business Architect and in the last column comments on how TOGAF 9 recommend the activities to be addressed.

Expected skills and activitiesBusiness AnalystBusiness ArchitectComments related to TOGAF 9
Is an intermediary between IT and the business users, follows the implementation strategy with respect to getting stakeholder buy-in and support.xxBoth roles require to be positioned between IT and business.
In particular business processes of a line of business.xThe Business Architect considers the organization’s strategy and less focused in a specific line of business.
Acts as catalyst to implement strategic and tactical change for the business.xxThe Business Architect will focus more on strategic changes.
Works with end-user groups to assist with aligning IT to the department’s business goals. Conduct feasibility studies to define the purpose, functions, and overall structure of business processesxxThe Business Architect in TOGAF 9 will use Business Scenario techniques.
May be involved in Business Process Management (BPM).xx
Performs analysis and documents business processes leading to process change and/or system implementation.xxThe Business Architect will model and process the business processes.
Operating as a more-or-less independent group that is focused on delivering BPM servicesxThe Business Architect will be working at a strategic level and will be less focused on the delivery of BPM services.
Does not have an IT background, but had, instead, a background in quality control.xThe Business Architect must have a perfect knowledge of the business.
Translates user requirements into software requirements that IT can then use to develop softwarexA Business Architect would not develop and review design specifications for software application. This would be the role of the Application Architect during Phase C.
Analyze and resolve software errors in a timely and accurate fashionxA Business Architect is not in charge of managing incidents linked to applications. IT operations may escalate this to the Development Team, or the vendor. Once a first level of diagnostic done, it will be transferred to one of the architects depending on the domain (technology, application).
Helps to develop and maintain software to support the business processes. Assist in developing system/application architecture.xThe Business Architect does not contribute to software development. This is done by the Solution Architect.
Leads and validates enterprise system designs across multiple business applications.xThe Business Architect does not lead Application Architecture. This will be done by the Application Architect and potentially the Solution Architect.
Creates and executes test plans to ensure that the functional and business requirements are met by the proposed solutionxThe Business Architect does not contribute to test plans. This is done probably by the Solution Architect.
Documents and defines processes, eliminating activities that don’t add value and straightening out the flow of the activities.xxIn the TOGAF 9 Phase B we would do this by documenting the baseline and target architecture and do a gap analysis, identifying the various business architecture building blocks to be eliminated.
Determining how business policies are implemented in business rules.xxBusiness rules have to be identified and implemented when business processes documented in both baseline and target architecture. Can be done at both strategic and tactical level.
Analyses customer needs and the processes customers go through to interact with an organization are key skills that any business process practitioner needs to be effective.xxBusiness scenarios would be used to identify business requirements.
Creates, manages and maintains an optimum business architecture that includes informational, organizational, process, performance and systems architecture.xThe Business Analyst focus more on projects delivery. The Business Architect is mostly focused on the delivery of the Business Architecture.
Defines, socializes and implements Business Architecture. Reviews roadmap projects for impact and compliance.xBusiness Architecture roadmaps will be delivered from the gap analysis.
Identifies and facilitates cross divisional continuous business improvement initiatives.xThe Business Architect works at a strategic level and focus mostly on Strategic Architecture.
Member of the Architecture Board, composed of representative process owners who approve any cross organizational business process changes.xBusiness Architects should be part of the Architecture Board.
Identifies and maintains an up to date picture of opportunities and risks.xxRisks have to be identified during both the Architecture vision phase and the development of the solution.
Experienced in business/process architecture including broad skills in the area of strategy mapping, business analysis skills, conceptual data and process modeling/design, EA frameworks.xThe Business Architect must have these skills. The Business Analyst may focus on process modeling only.
Strong work experience in Project and Change management.xxBoth roles require these skills.
Proven track record for working effectively with technical and business functions.xThe Business Architect must work with other domain’s architects.

My observations are:

Business Analysts are much closer to IT. They often are assigned to a specific Line of Business, which is close to the Development Team, and are implicated in software development. They may be part of the Development Team or the Project Management Office. The Business Architect reports to managers or senior managers who may be business or IT but are independent of any project. They have a global view on most business and will be responsible for modeling the business as a whole, then working top down to “architect” encompassing end to end business processes. Their role is more horizontal and is considered a neutral voice and because of that will make more critical decisions than a Business Analyst.

Business Analysts document requirements as defined by users during workshops. A Business Architect documents and may contribute to define a business strategy using requirements provided by the users if that strategy is not finalized. The Business Architect must have the ability to think in both a strategic and tactical manner whereas a Business Analyst is normally tactical.

The Business Analyst operates within the confines of a predetermined application and technology architecture. A Business Architect is a part of the decision making process to define the IT architecture (Data, Application and Technology). He will have a strong influence directing information technology to meet business needs, and assist in identifying business inefficiencies and opportunities.

Business Architect must be cognizant of enterprise strategies whereas a Business Analyst is normally concerned with specific projects independent of enterprise strategy.

8 years, 9 months ago

Updates Harmful

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…

8 years, 10 months ago

Book 2.0

I am pleased to announce that the book, State of the eUnion: Government 2.0 and Onwards, is now in production and will be available for ordering in your favorite bookshop very soon. But wait, there’s more: On 18 November, the free, online version will be available from 21gov.net. Read the press release. Follow the book

8 years, 10 months ago

IT Profession? I think not

Recent tweets from @rsessions, @richardveryard, @j4ngis,@cybersal have been looking at how hard various professions are. @richardveryard’s observation that “@j4ngis @oscarberg Rocket science isn’t even particularly complicated. Goes up, comes down. It …

8 years, 10 months ago

A rant on "SOA Projects"

The appearance of the SOA Manifesto has led me to look closely to the naming of projects and the implications of such names.Time and time again I see projects titled or described with a technology or architecture in the name. How often do we hear, “The…

8 years, 10 months ago

The role of the Solution Architect during the implementation

In my previous article I describe the role of the Solution Architect within the TOGAF ADM, mostly acting between phases E to G, with a specific focus on E (Opportunities and Solutions) and F (Migration Planning). This article will cover the role in phase G: Implementation governance.

The objective of that phase is to formulate recommendations for each implementation project, and govern and manage an architecture contract covering the overall system implementation and deployment. In companies where the maturity is high, it would be perfectly acceptable to have the Solution Architect acting in the name of the Enterprise Architecture team and coordinate activities during the phase G.

TOGAF defines objectives during that phase and each of them may be detailed as follows.
To formulate recommendations for each implementation project (Source: TOGAF 9)

The Solution Architect with the Enterprise Architecture team and the Development Team:

  • Participates in assessment of solutions needs consistent with the global business strategies
  • Re-analyzes business practices.
  • Provides business analysis and documents process design of system functions and processes as identified in the phase B.
  • Recommends application design within the development team. Supervises and ensures quality delivery of the analysis, design, and build of the hardware, network, and common software platform components of software releases with the development team.
  • Assesses identified technologies from the phase D, and makes sure that solution options are based on the target architecture. Note: He will be directly accountable for the acceptance of technology architecture deliverables by the client.
  • Participates in the planning, development, maintenance, installation, configuration, documentation, training and implementation of new applications/solutions. He is accountable for the documenting requirements (hardware, network, and configuration) captured during the previous ADM phases. He may also develop the engineering documentation.
  • Participates in the development of functional specifications for developers related to modifying functionality, report development, outputs and interfaces.
  • Works with internal customers, external consultants, IT staff and other stakeholders to refine requirements when needed.
  • Leads and participates in developing and facilitating end user workshops for the solution.
  • Supports existing applications within the company’s active portfolio and extends their use where appropriate according to the gap analysis.
  • Coordinates and/or participates in the planning and execution of application testing.

To govern and manage an Architecture Contract covering the overall implementation and deployment process (Source: TOGAF 9)

He identifies if there are any issues between the architecture and the implementation organization.

To perform appropriate governance functions while the solution is being implemented and deployed (Source: TOGAF 9)

He will refer to existing governance best practices such as IT Service Management, Project Management, Risk Management, Security Management, and Audit management (for example).

To ensure conformance with the defined architecture by implementation projects and other projects (Source: TOGAF 9)

He will Review ongoing implementation governance and architecture compliance for each building block.

To ensure that the program of solutions is deployed successfully, as a planned program of work (Source: TOGAF 9)

He will Review ongoing implementation governance and architecture compliance for each building block.

To ensure conformance of the deployed solution with the Target Architecture (Source: TOGAF 9)

He will support the architecture design review using a customized checklist as defined in TOGAF.

To mobilize supporting operations that will underpin the future working lifetime of the deployed solution (Source: TOGAF 9)

The Solution Architect with the Enterprise Architecture team and the IT Operation Team:

  • Helps to monitor and supports the operations architecture of for hardware, network, and common software platforms (including configuration approach, deployment, approach, and monitoring approach).
  • Supports all hardware, network, and common software platforms in Development, Production, and Operations environments. Must be aware of the status of the system in all environments, and must communicate and manage environment related risks and activities.
  • Supports build team by managing configuration of hardware, network, and common software platforms (like Application Servers).
  • Establishes and maintains relationship with key clients with-in client IT organization.
  • Develops and implements plan for increasing level of technical architecture skill in program staff.
  • Ensures consistent implementation of technical components across release activities with the IT Service Management team if it exists (e.g. release manager).
  • Identifies production infrastructure related issues in the production environment with the help of both the Service Desk and the System Management team if they exist. Creates and implements issue resolution plans that have to be escalated to the Enterprise Architecture team.

This diagram is a high level representation of the Solution Architect’s activities interacting with all parties involved in the architecture development and delivery.


This approach where many activities are led by a designated Solution Architect. The alternative being to share the role between several architects from the Enterprise Architecture team.

8 years, 10 months ago

The role of the Solution Architect during the implementation

In my previous article I describe the role of the Solution Architect within the TOGAF ADM, mostly acting between phases E to G, with a specific focus on E (Opportunities and Solutions) and F (Migration Planning). This article will cover the role in phase G: Implementation governance.

The objective of that phase is to formulate recommendations for each implementation project, and govern and manage an architecture contract covering the overall system implementation and deployment. In companies where the maturity is high, it would be perfectly acceptable to have the Solution Architect acting in the name of the Enterprise Architecture team and coordinate activities during the phase G.


TOGAF defines objectives during that phase and each of them may be detailed as follows.

To formulate recommendations for each implementation project (Source: TOGAF 9)

The Solution Architect with the Enterprise Architecture team and the Development Team:

  • Participates in assessment of solutions needs consistent with the global business strategies
  • Re-analyzes business practices.
  • Provides business analysis and documents process design of system functions and processes as identified in the phase B.
  • Recommends application design within the development team. Supervises and ensures quality delivery of the analysis, design, and build of the hardware, network, and common software platform components of software releases with the development team.
  • Assesses identified technologies from the phase D, and makes sure that solution options are based on the target architecture. Note: He will be directly accountable for the acceptance of technology architecture deliverables by the client.
  • Participates in the planning, development, maintenance, installation, configuration, documentation, training and implementation of new applications/solutions. He is accountable for the documenting requirements (hardware, network, and configuration) captured during the previous ADM phases. He may also develop the engineering documentation.
  • Participates in the development of functional specifications for developers related to modifying functionality, report development, outputs and interfaces.
  • Works with internal customers, external consultants, IT staff and other stakeholders to refine requirements when needed.
  • Leads and participates in developing and facilitating end user workshops for the solution.
  • Supports existing applications within the company’s active portfolio and extends their use where appropriate according to the gap analysis.
  • Coordinates and/or participates in the planning and execution of application testing.

To govern and manage an Architecture Contract covering the overall implementation and deployment process (Source: TOGAF 9)

He identifies if there are any issues between the architecture and the implementation organization.

To perform appropriate governance functions while the solution is being implemented and deployed (Source: TOGAF 9)

He will refer to existing governance best practices such as IT Service Management, Project Management, Risk Management, Security Management, and Audit management (for example).

To ensure conformance with the defined architecture by implementation projects and other projects (Source: TOGAF 9)

He will Review ongoing implementation governance and architecture compliance for each building block.

To ensure that the program of solutions is deployed successfully, as a planned program of work (Source: TOGAF 9)

He will Review ongoing implementation governance and architecture compliance for each building block.

To ensure conformance of the deployed solution with the Target Architecture (Source: TOGAF 9)

He will support the architecture design review using a customized checklist as defined in TOGAF.

To mobilize supporting operations that will underpin the future working lifetime of the deployed solution (Source: TOGAF 9)

The Solution Architect with the Enterprise Architecture team and the IT Operation Team:

  • Helps to monitor and supports the operations architecture of for hardware, network, and common software platforms (including configuration approach, deployment, approach, and monitoring approach).
  • Supports all hardware, network, and common software platforms in Development, Production, and Operations environments. Must be aware of the status of the system in all environments, and must communicate and manage environment related risks and activities.
  • Supports build team by managing configuration of hardware, network, and common software platforms (like Application Servers).
  • Establishes and maintains relationship with key clients with-in client IT organization.
  • Develops and implements plan for increasing level of technical architecture skill in program staff.
  • Ensures consistent implementation of technical components across release activities with the IT Service Management team if it exists (e.g. release manager).
  • Identifies production infrastructure related issues in the production environment with the help of both the Service Desk and the System Management team if they exist. Creates and implements issue resolution plans that have to be escalated to the Enterprise Architecture team.

This diagram is a high level representation of the Solution Architect’s activities interacting with all parties involved in the architecture development and delivery.


This approach where many activities are led by a designated Solution Architect. The alternative being to share the role between several architects from the Enterprise Architecture team.