Speaking at 2 conferences in February

I will be delivering a speech at the next Open Group Conference in San Diego on the subject of Architecting the Cloud, February 9, 2011.

Taking place at 9:45am, “Cloud Computing requires Enterprise Architecture and TOGAF™ 9 Can Show the Way “

Abstract: Most companies doing Enterprise Architecture are wondering how to approach Cloud Computing and how does it fits in TOGAF 9. This presentation is a suggested approach which has been used by some companies.

Key takeaways:

• When does it make sense to use Cloud Computing in a company which does Enterprise Architecture
• What suggested additional activities may be included in the TOGAF 9 ADM

For further information on the event, please visit:

http://www.opengroup.org/sandiego2011/

 

I’m also excited to be on the program at the upcoming Enterprise Architecture Management Forum in Frankfurt, Germany, February 22-23, 2011.

I will be presenting at the conference on the subject of EA Governance.  This event is one of the leading conferences for Information Technology in Germany, with speakers and participants representing companies such as Volkswagen, Deutsche Bank, Deutsche Post, Heidelberger Druck and others.

Taking place at 2:30pm on February 22, “Enterprise Architecture Governance – Why? A need for transparency and better control” addresses:

• Governance and why we need it
• The importance of processes, roles, responsibilities, and skills
• Definition of the components and related activities
• Case Study for a successful Enterprise Architecture governance using TOGAF

The conference also features several additional topics high on the importance list of technology professionals:

• Business IT Alignment
• Innovation Management
• EA and Cloud Computing
• EA Governance
• Agility
• Project Portfolio Management
• Best Practices, Tools and Anti Patterns

For further information on the event, please visit: http://www.iir.de/eam.

Cloud Computing requires Enterprise Architecture and TOGAF 9 can show the way

Enterprise Architecture is necessary regardless of changes to underlying technologies. If managed properly, Enterprise Architecture will iterate and adjust to the winds of change. Client/server, SOA, RFID, Cloud, and other technology developments should be considered as styles, but Enterprise Architecture is at the heart of change. Cloud computing should have little impact on Enterprise Architecture.

It is the role of the Enterprise Architecture team to:

· Investigate if any style is simply hype or whether it holds real business value

· Understand the benefits and risks of a specific style

· Communicate these to Business and IT

· Develop an adequate governance framework

· Align the “style” with business requirements

· Give guidance for sustainable innovation

If Cloud computing does not take Enterprise Architecture into consideration, it will result in “spaghetti clouds” (aligned with “spaghetti architectures”).

Cloud computing is often characterised by: virtualised computing resources, seemingly limitless capacity and scalability, dynamic provisioning, multi-tenancy, self-service and pay-for-use pricing. Enterprise Architecture can help to make the shift to cloud computing smooth.

For organisations focusing more on Technology Architecture, Cloud computing could be a “big hit”. But for businesses that want to successful adopt cloud computing in a way that aligns to their business strategy, Enterprise Architecture is imperative (refer to above diagram).

Cloud computing may be a fit when the core of internal Enterprise Architecture is mature. This means:

· As recommended in TOGAF. well defined and layered:

o Business Architecture

o Application Architecture

o Data Architecture

o Technology Architecture

· Well defined interoperability (ADM Guidelines and Techniques)

· Low level of security agreed (during the Architecture Vision)

· Web as a target

· Costs issues

· New products and services

Cloud computing may not be a fit when the core of internal Enterprise Architecture is immature. This means:

· Business, Application and Data architectures are tightly coupled

· Low level of interoperability defined

· High level of security required

· When applications have IPAs (Information Provider Applications) with only proprietary interfaces

· When solutions are legacy

Where there is could be a good fit, a TOGAF iteration should then be “Cloud Architecture aware”. The Enterprise Architecture team drives the programme and works collaboratively with both the business and the IT department.

In the Preliminary Phase we should consider the addition of a step related to the creation of a strategy for the consumption and management of cloud services (public/private clouds, semantic management, security, transactions). The governance framework also needs to include the processes, roles and responsibilities related to cloud services and operations. At this stage, we need to identify who in the business owns the cloud from both a user and service provider management perspective. New principles may be created referring to the Cloud when the organisation has a fairly mature Enterprise Architecture (maturity model) in order to fully take advantage of the Cloud.

During Phase A, you may use a Business Scenario where you would identify in a workshop what are the business problems, business Requirements and identify a potential business solution. Stakeholders in this workshop may come from Business and IT Operations, Procurement, PMO, Data Center, Development, COO/CIO/CTO. Interoperability will be an important element of the phase. The Enterprise Architecture team will collaborate with the business to understand and scope the needs; align them with the Strategic Enterprise Architecture (bringing to bear the existing technological capabilities that can satisfy those needs thereby promoting sharing, reusing or building new ones if needed). Given the relatively low barrier to entry, in the scenarios where the Business is not sure of the viability of their proposal, they could go straight to the Cloud instead of "experimenting" before solidifying their requirements. The result of this is that the business may embark on a path of no return. To avoid this, make sure that the Business Scenario is complete, only refer to business solutions without referring to any architecture style (as this will be discussed during Phase E) and signed off.

Start the architecture considering Phase B, C and D.

At that stage, it is be recommended that you consider a Cloud Reference Model. This is a description of the appropriate Cloud industry standards, the dimensions of the Cloud problem space, and the decisions and choices that apply to a Cloud computing for an organisation. A Cloud reference model, reference architecture and reference implementation approach is an accepted approach for planning and implementing Cloud computing. Different Cloud Reference Models can be considered such as those published by

· The Open Cloud Consortium

· The Cloud Security Alliance

· The Cloud Computing Reference Model (CC-RM) and Reference Architecture framework from AgilePath

· The Accenture Cloud Reference Model for Application Architecture with its 7-layers. Like the OSI Model for networks, this Cloud Model is layered to separate concerns and abstract details

There is also an on-going initiative by the Open Group to deliver a Cloud Reference Model.

The Security activities from TOGAF will have to be applied to all phases taking into account the company’s Security strategy. The TRM should be extended with cloud services.

In phase C: Data Architecture, Data integration, in particular may be an issue for cloud computing as it pushes information back into siloes, that IT may not have direct access to. It is also recommended to determine Data and privacy classification and to prioritise the risk criteria of what goes in the cloud and what stays on-premise.

During phase E and F there is a need to understand the Cloud resources which may exist or not. A new step will also be dedicated to identify candidates’ services in the Cloud.

Instead of now having to provide standardized ROI or cost-benefit analysis justifying the products that need to be bought or charge-backs that need to be agreed upon upfront for shared assets, the Business can provide operational expenditure outlines and may go out to the Cloud to source their requirements. No surprises with CapEx, decreased new product introduction training line item expenditures (many products are “standards “which means, lots of documentation and books available, e-learning, etc.), different charge-back agreements between Finance and Business Units (the organisation may have accesses to the service independently from his internal structure), in short, no need to conform to existing enterprise-wide Reference Architectures to meet individual project needs. In relation to this, the recent Open Group white paper “Building Return on Investment from Cloud Computing” is a valuable source of information.

During Phase G, activities may also include the relocation of:

· Business processes (Process-as-a-Service)

· Applications (Application-as-a-Service)

· Data (Information-as-a-Service and Database-as-a-Service)

· Technical services (Storage-as-a-Service and Infrastructure-as-a-Service).

· Security and operations implementation will have to be taken into consideration during the relocation. Security can also be considered as Security-as-a-Service.

The following diagram summarises the additional activities or concerns which should be considered in the ADM:

Below is a diagram which maps the various Cloud services to the TOGAF Metamodel.

The development and deployment teams would now be sourcing from and conforming to the Cloud API and services, without the Enterprise Architecture team becoming policeman, enforcing the reference architectures or corporate standards at various checkpoints (compliance and dispensation activities will remain for internal new systems). With overarching cross-project oversight not relevant anymore, each project would tend to work in its own Cloud development sandbox, party engendered by the partitioning paradigm of the Cloud itself.

Barring some exceptions, traditionally the Enterprise Architecture team has not been relevant to the Operation side of the organisation, but with the Cloud, even that seems to be disappearing. The Cloud providers will furnish the relevant tools for management and reporting and take away the onerous tasks of patch management, version upgrades, high availability, disaster recovery and the like.

New technologies styles are exciting, but using technology styles just for the sake of technology does not bring a real value. Technology use should be driven not by its "coolness factor", but rather by business requirements and an underlying Enterprise Architecture such as TOGAF. Moving some applications to the Cloud can make some infrastructures go away, but badly designed solutions won’t be improved by relocating to the Cloud.

What is Enterprise Analysis: does it differ from Enterprise Architecture?

Enterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?

At first sight, business opportunities are not always considered as being part of an Enterprise Architecture initiative, more as an activity which should be considered as an input. But let’s look at this in more detail.

Let’s look at this in more detail by way of mapping activities between BABOK v2* and the TOGAF 9 Framework*. The BABOK is the collection of knowledge within the profession of business analysis and reflects generally accepted practices. It describes business analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in the execution:

BABOK v2 Knowledge Area Activity in Enterprise Analysis	Definition	Enterprise Architecture (e.g TOGAF 9)	Differences, observations
Requirements Elicitation	This describes the interview and research process-how to best extract needs from stakeholders (and even how to recognize needs they don't know they have).Elements such as metrics (tracking the amount of time spent eliciting requirements) and elicitation techniques (prototyping and brainstorming are just a couple) among the topics covered	Phase A: Architecture Vision is the initial phase of an architecture development cycle. It includes information about scope, the key steps, methods, information requirements and obtaining approval for the architecture development cycle to proceed	Business scenarios are a useful technique to articulate an Architecture Vision. A Business Scenario describes, a business process, an application or set of applications enabled by the proposed solution , the business and technology environment, the people and computing components (called “actors”) who execute it, the desired outcome of proper execution To build such a Business Scenario, workshops with business users (stakeholders) would be organized
Business Requirements Analysis	This describes how to write/state requirements that will meet business needs. Key objectives include methods for prioritizing and organizing requirements, as well as the most beneficial techniques for requirements presentation (including state diagrams, prototyping, data flow diagrams, and process modeling, and more). Business Requirements for future project investments are identified and documented. They are defined at a high level, and include goals, objectives, and needs are identified	Business Requirements are collected from business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above). That document identifies what will be the business solutions in generic terms	The Enterprise Architects will define the Architecture Vision phase based on the goals, and objectives of the enterprise gathered from the business. There are two steps: 1. Business people will have defined the goals and the objectives of the enterprise independently from the Enterprise Architecture team 2. The Enterprise Architecture team which include business people gather the requirements based on the previous activity
Enterprise Analysis	Begins after a Business executive team develops strategic plans and goals This outlines the crucial (and sometimes political) process of keeping everyone in the loop and on the same page regarding project's direction and progress. This activity delves into such details as the requirements review and approval processes (including record-keeping).	Most of these activities are taken into account in doing Enterprise Architecture or done directly by the Business executive team before starting an new Enterprise Architecture project
	Strategic plan development		Done outside of the Enterprise Architecture process by business people but is a key source of information
	Strategic goal development		This is done outside of the Enterprise Architecture initiative by business people but is a key source of information
	Business Architecture development		Done during Phase B:Business Architecture, looking at the baseline and target architecture, delivering a gap analysis, a plan and a roadmap
	Feasibility Studies		Done during Phase A: Architecture Vision (with a Business Scenario)
	Business Case Development		Done during Phase A: Architecture Vision (with a Business Scenario)
	New Project Proposal		This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning
	Selecting and Prioritizing New Projects		This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning
	Business Opportunities		This is done during the Phase A: Architecture Vision and the Phase E: Opportunities and Solutions
	Launching New Projects		This is done during Phase F: Migration Planning
	Managing Projects for Value		This is done during Phase F: Migration Planning
	Tracking Project Benefits		Once the project is in production, it is no longer part of the Enterprise Initiative
Solution Assessment and Validation	Details how to choose the best solutions for specific business needs (as well as assessing how well the chosen solution worked after its implementation).This should also cover risks, dependencies, and limitations that must be identified before proposing any solution	Solutions are identified during Phase E.: Opportunities and Solutions. This phase is directly concerned with implementation, identifying major work packages to be undertaken and creating a migration strategy. Risk management, dependencies are taken into consideration.
Business Analysis Planning and Monitoring	Explains how to decide what you need to do to complete an "analyst effort" (in other words, how to plan a project). This helps intelligently decide which stakeholders, tools, tasks and techniques we will need to get the job done	Covered mostly in the Architecture Vision phase, then in the Business Architecture Phase	Stakeholder management techniques are used within TOGAF, tools and techniques are identified in the Business Architecture phase (modeling, reference models, viewpoints)
Requirements Management and Communication	Describes how to identify business needs (the why of the project; whereas requirements are the how) and state the scope of their solutions. This is a crucial piece of the analyst's work. SMART criteria of measurement, SWOT analysis and other measurement factors that make identifying this root cause data objective and tangible are used	Business Requirements are collected with the business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above).	SMART techniques are equally used. Communication plans are defined.

 

This diagram below is a draft map BABOK® and TOGAF 9; more work is required!

 

Observations

There are obviously overlaps between Enterprise Analysis and Enterprise Architecture, but activities are not always done in the same sequence.

• Enterprise Analysis is more a business initiative than an Enterprise Architecture which includes both business and IT people
• Enterprise Analysis provides the context in which an Enterprise Architecture should be conducted
• Enterprise Analysis is about defining the strategic goals and the strategic planning taking into account the environment and market trends, identify business issues, focus on remaining competitive, profitable, efficient. Enterprise Architecture is reusing all this information.
• Enterprise Analysis is only covering the initial activities of Enterprise Architecture but does not address other Enterprise Architecture activities such as: - Application Architecture, Data Architecture, Technology Architecture (and Solution Architecture).
• Enterprise Analysis does not include all aspects related to governance such as the IT Governance and the Enterprise Architecture Governance Framework. Touch points with other frameworks are not addressed.
• Enterprise Analysis may not completely address the need of working with other parts of the enterprise such as IT, PMO, development teams, IT partners.
• Enterprise Architecture suggest a Preliminary phase which is about defining ‘‘where, what, why, who, and how” Enterprise Architecture will be done, establishing the business context, customizing the framework, defining the architecture principles, establishing the Architecture Governance structure.

Enterprise Analysis complements Enterprise Architecture but also overlaps in some areas. Organization looking into Enterprise Architecture and specifically TOGAF 9 may consider adopting a Business Analysis framework such as BABOK and integrate them in the Preliminary Phase. If both approaches exist in a company, this would be a great opportunity for optimizing the alignment between Business and IT, and to run an Enterprise Architecture program from a complete business perspective.

About Business Analysis Body of Knowledge® (BABOK®)

The Business Analysis Body of Knowledge® (BABOK®) is the collection of knowledge within the profession of Business Analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the Business Analysis professionals who apply it in their daily work role. The BABOK® Guide describes Business Analysis areas of knowledge, their associated activities and the tasks and skills necessary to be effective in their execution. The BABOK® Guide is a reference for professional knowledge for Business Analysis and provides the basis for the Certified Business Analysis Professional™ (CBAP®) Certification.

BABOK® Guide 2.0 represents the development of a common framework to understand and define the practice of business analysis.

http://www.theiiba.org/am/

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 activities	Business Analyst	Business Architect	Comments 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.	x	x	Both roles require to be positioned between IT and business.
In particular business processes of a line of business.	x		The 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.	x	x	The 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 processes	x	x	The Business Architect in TOGAF 9 will use Business Scenario techniques.
May be involved in Business Process Management (BPM).	x	x
Performs analysis and documents business processes leading to process change and/or system implementation.	x	x	The Business Architect will model and process the business processes.
Operating as a more-or-less independent group that is focused on delivering BPM services	x		The 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.		x	The Business Architect must have a perfect knowledge of the business.
Translates user requirements into software requirements that IT can then use to develop software	x		A 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 fashion	x		A 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.	x		The 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.	x		The 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 solution	x		The 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.	x	x	In 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.	x	x	Business 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.	x	x	Business 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.		x	The 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.		x	Business Architecture roadmaps will be delivered from the gap analysis.
Identifies and facilitates cross divisional continuous business improvement initiatives.		x	The 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.	x		Business Architects should be part of the Architecture Board.
Identifies and maintains an up to date picture of opportunities and risks.	x	x	Risks 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.		x	The Business Architect must have these skills. The Business Analyst may focus on process modeling only.
Strong work experience in Project and Change management.	x	x	Both roles require these skills.
Proven track record for working effectively with technical and business functions.		x	The 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.

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.

Enterprise Architecture, TOGAF and Solution Architects

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:

· Strategic business acumen (understand business requirements and strategy)
· Technical analysis
· Broad and deep technical knowledge
· Technical leadership (the trusted, technical advisor for assigned line of business, providing thought leadership and application of technology to business problems)
· Data Architect
· Shapes the evolution of company’s products
· Maps product requirements and business problems to re-usable end-to-end technology solutions
· Uses methodologies and frameworks (using best practices and common patterns, including database, component layers, user interfaces, web services, and integration patterns)
· Builds and deploys new functionality and extend applications (driving the development of those solutions by guiding and mentoring the development team through the entire development process. Some development will be required for shared services and components or technically challenging areas where the skills of an architect are needed).
· Software architect (must understand and contribute to all levels of design needed for the solution (business, data, application, technology))

· Deep experience developing enterprise solutions using all aspects of the .NET platform, open source or Java (or any other environment), Web Services, multithreaded programming, designing and building frameworks, enterprise patterns, SQL design and development, and database tuning
· Coder (build and code prototypes and frameworks)
· Hands-on experience
· Performance and load testing, development tools
· Works with major lines of business and IT Development teams
· Is a member of the Enterprise Architecture team
· Documents solution designs and how they interact with the larger Enterprise Architecture

Now looking at TOGAF, we need to consider a few definitions such as the Architecture Building Blocks (ABBs) and the Solutions Building Blocks (SBBs).

Building Block – A (potentially re-usable) component of business, IT or architectural capability

• Architecture Building Block (ABB)

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

• Solutions Building Block (SBB)

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.

Development of an Enterprise Architecture Communication Plan

As a strategic activity for IT, communication is important for the effective management of both internal and external relationships. The IT function in many organizations operates with highly diverse stakeholders from different parts of the world. The situation has evolved rapidly over the last years through (standardization, globalization, and optimization…).

Communication significantly impacts how IT is perceived by the organization, and therefore it plays a crucial role in the successful positioning of IT as an internal partner. Moreover, given the competitive market pressure the position of IT within the company is the same that of an external IT provider. Hence the same level of professionalism in terms of quality and efficiency are demanded.

Communication concerns all business and IT employees whether they are managers, staff assigned to communication roles, or IT employees with technical tasks. Internally, multinational companies and global departments demand excellent communication and intercultural skills from employees and managers. This philosophy holds true for the field of IT. Smooth working processes and good performance are dependent on effective communications, especially in periods of change.

Effective communication is part of the overall plan for management of an Enterprise Architecture Program. An Enterprise Architecture communication document has to identify stakeholders of the organization’s Enterprise Architecture Program, the information needs of those stakeholders, and the communication strategy to be followed by the program in meeting those needs.

The goals of the Architecture Board, as established by (usually) the organization’s Management Committee’s mission and charter, requires a successful communication strategy. The Enterprise Architecture and the operations of the program charged with evolving that architecture are important topics that must be communicated by the program if the Enterprise Architecture initiative is to succeed.

The plan consists of sections devoted to an identified stakeholder group (you may reuse the stakeholders management defined in TOGAF). Within each section, the plan would identify:

• The members of the stakeholder group
• The TOGAF Enterprise Architecture Framework role(s) to which the stakeholder group maps
• The information needs of the stakeholder group defined in the Architecture Vision The communication strategy to be followed by the program in meeting the information needs of the stakeholder group
  

This plan should be a living document, and as such should be updated on a regular basis to reflect new stakeholder groups, new information needs, and new communication strategies. It is important that the Enterprise Architecture Program be held accountable for implementation of this plan, and that the Architecture Board regularly reviews progress with the Program Director.


Stakeholder General Communication

Stakeholders are people who have key roles in, or concerns about, the system. Different stakeholders with different roles in the system will have different concerns. Stakeholders can be individuals, teams, or organizations (or classes thereof).

The list of stakeholders can be also based on the existing Business and IT organization and structure. It also takes into consideration recommendation from HR department addressing the various ways of communicating to various groups of people.

The various stakeholders may include (examples):

- Executive Management Board
- C-levels
- Business Users Advisory Board
- Business Units
- Procurement
- Architecture Board
- IT Units
- Enterprise Architecture team
- Customers
- Developers

The communication plan should take into consideration all groups (use best practices from EA frameworks such as TOGAF), the IT organization and the HR recommendations.

These groups will have to be clearly defined as probably some of the communication tools and techniques will have to be tailored for each community.


General Information Needs

The following information needs to be applied to all stakeholders.

1. Understand what Enterprise Architecture is (at least at a high level)
2. Understand the value, benefits, and importance of Enterprise Architecture to the business.
3. Understand how the Architecture Board and Enterprise Architecture Program are contributing to the pursuit of the organization’s business objectives.
   

General Communication Tools

To meet these general information needs, the Enterprise Architecture Program should implement the following communications tools.

1. A set of basic information materials describing the scope of the Enterprise Architecture. This set of materials will describe the value, benefits, and importance of Enterprise Architecture. The materials will be brief and concise, and may consist of: one-page briefing or brochure, key concept map, Frequently-Asked Questions (FAQ) document, position paper, and a presentation.
2. In all status reporting, Committee and Program achievements will be explicitly linked to the organization’s business objectives.
3. The basic Enterprise Architecture scope and value materials, as well as some high-level business-oriented status information, will be available (and prominently displayed) on the Enterprise Architecture website. These materials should be suitable for use/delivery by Architecture Board members as well as program staff. (The use of systems such as a CMS (Content Management System)would allow delivering information based on roles.)
   

Communication Matrix

A matrix should then be built which associates the various communication tools to the various stakeholders (see example below)

This matrix associates the communication tools to the various stakeholders. Each stakeholder, communication tool should then be described in that document and be related to various steps of the Enterprise Architecture governance.

The various views will also have to be defined in annexes.

Communication Planning

A Communication planning will have to be defined (see example below).

Implementation steps

To implement such a communication plan, the following steps will have to be completed:

1. Validate if all stakeholders have been taken into consideration
2. Define the content of each communication tool (reports, newsletters, verbal communication, etc.)
3. Ensure that the appropriated communication tools are associated to the right stakeholders
4. Implement the Communication Plan with the Business and the IT Department
5. Once all communication tools are formalized and approved, identify the Business Units and roll out the communication plan to these stakeholders
6. Once on board, roll out the communication plan to the Executive Management Board and C-levels

Should the IT Strategist role disappear with Enterprise Architecture?

Many companies in their IT department have two units: IT Strategy & Planning and Enterprise Architecture. As regularly these are two different people managing these units, there is a high risk this ends up in serious conflicts.

The IT Strategist needs to understand the organization’s overall business strategy and is supposed to develop a comprehensive IT Strategic Plan that aligns with the business strategy (linkage, support of goals and objectives, etc.). He will continually assess all areas in the IT department to make sure their efforts and initiatives support this IT strategic plan, highlight gaps and identify alternatives to close gaps. During the development of the IT Strategic Plan (creation and maintenance of a detailed project plan (schedule, WBS, etc.) for the development and execution) , he interacts with various IT and Business Governance committees, and supports the execution and the evaluation of that plan.

How much is this different from one of the role of any Chief Enterprise Architect?

Among various roles the Chief Enterprise Architect ensures that the organization’s strategy is understood and acted on. Ideally, he should contribute to the strategy itself. He also has to understand, advocate and support the organization’s business and IT strategies.

Enterprise Architecture should be used to develop an IT Strategy. The EA team is in charge of implementing an EA program, which involves articulating the desired future state, understanding the current state, identifying the gaps between the two states and developing approaches to close these gaps. The team is leading the creation or evolution of the EA function or program, including the coordination of an appropriately balanced pursuit of enterprise business, information, application, technology and solution architecture viewpoints. Understand new technology future IT directions and how they can Impact the business.

When creating the new architecture (blueprint or high level architecture) which is based on the business goals and directions, they will identify new technology options and key finding from IT assets mapping and technology as-is mapping. The gap analysis will document each element that we mapped in the current state and translate this into roadmaps with dependencies and assignments: group gaps into projects, write one page of project high level analysis, assign resources to projects and creating a road map.

MODAF Acquisition Views will help to define these projects including dependencies.

FEAF in section 4 EA Transition Strategy / TOGAF Phases E (Opportunities and Solutions) and F (Migration Planning) describe similar activities.


Enterprise Architecture is a bridge to make the connection between business side planning and enterprise IT strategy making. When successful it delivers the IT strategy documentation.

The role of the IT Strategist should be split into two sets of activities (Enterprise Architecture and PMO (project management office) and does not make anymore sense when an organization has these two units.

Aligning ITIL V3 Service Design with TOGAF 9

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:

• Design of the service solutions
• Design of the Service Portfolio (and other supporting systems)
• Design of the technology architectures and management systems
• Design of the processes
• Design of the measurement systems, methods and metrics
  

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:

• Business Architecture: for Business, organization and enterprise
• Data Architecture: for data and information, databases
• Application Architecture: for applications
• Technology Architecture: for hardware (desktops, mobile devices, servers, and mainframes), network, telephony and software
  

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:

• Service Level Management
• Availability Management
• IT Service Continuity Management
• Supplier Management
• Information Security Management
• Capacity Management
• Service Catalogue Management
  

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!

TOGAF 9 Migration Planning and Project Portfolio Management

Phase F in TOGAF helps to describe how to create a viable implementation and migration plan in co-operation with the portfolio and project managers. Very often companies already have in place a Project Portfolio Management framework and there may be a need to integrate your enterprise architecture with that.

As an example, PMI has introduced a standard for Portfolio Management, and portfolio managers have a resource to help them develop professionally and achieve success for themselves and their enterprise. Within an organization, a portfolio represents a collection of active programs, projects and other work undertaken at a specific point in time to help the organization achieve strategic objectives. In essence, a portfolio reflects the priorities, investments and resource allocations.

Project Portfolio Management (PPM) may be part of an enterprise governance framework. It is a management process designed to help the organization-:

-To ensure that the organization is doing the "right things", optimally allocating scarce resources toward the enterprise’s objectives
-To acquire and view information about all projects
-To sort and prioritize each project according to certain criteria, such as strategic value, resource impact, cost, and so on.

PPM has several activities which are similar to the objectives of managing a financial portfolio:

-The identification of all the individual demands in the portfolio
-The development of a "big picture" view and a deeper understanding of the collection as a whole
-The sensible sorting, adding, and removing of items from the collection based on their costs, benefits, and alignment with long-term strategies or goals.

In a nutshell, Portfolio Management can help zero in on the projects that are most worth their effort; project management can help execute those projects most efficiently.

These activities can be perfectly integrated with Phase F of TOGAF. Once the work packages, projects and building blocks inventory is created, the enterprise architecture team with the portfolio managers (and other important stakeholders) will examine each project and prioritize it according to established criteria. They will probably assign a business value; conduct a cost business analysis for each project (done in collaboration with business people); identify the risks to the projects.

The overall list of projects is then considered to develop a well-balanced list of supported projects and provide an input for a detailed implementation and migration plan. It will also help to confirm the Transition Architecture defined in the phase E. The use of an Architecture definition increments table is highly recommended to list these projects.

Some projects will be given high priority and extensive support, some will be given moderate priority, and still others will be placed on hold or dropped entirely from the list. This will also help to finalize the Architecture roadmap. Finally, resources will need to be identified and made available.

Other Governance domains may also be to be integrated in the PPM process and Phase F, such as Risk Management (e.g. RiskIT), Project Management (e.g. PMI, PRINCE 2), etc.

Companies who are mature in Portfolio Management activities may integrate their existing work practices easily with TOGAF. This would enforce the relationship between the Enterprise Architecture team and the PMO (or the PPM team).

(You can also refer to another post: Why do we not find yet links between Enterprise Architecture and Project Portfolio Management? )

Keep an eye on OneCMDB and the CMDB Federation

OneCMDB Version 2.0 is a real interesting concept and product as this may be one of the first IT Service Management solution developed in an Open Source mode. It will not replace your Service Desk solution but may help companies with limited budget or companies which have a wide diversity of existing catalogs of assets. It is only covering Configuration Management as a process and in some way IT Assets management. For those who are using Nagios, there exist some connectors.

This has been initially developed by Lokomo Systems using Java but I’m not sure how does that fit with the CMDB Federation Group (I wrote a post on the subject in 2007) if it still exists….(I haven’t seen any indication of activity since January 2008 and maybe this is a dead project…).

In any case, keep an eye on both…

Deliverables, Artifacts And Catalogs-Matrices: Some examples

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.

Enterprise Architects should ensure that their efforts to create architecture documentation produce meaningful results by creating artifacts that connect with the consumer, drive decisions, and will allow the development of reusable building blocks.

If we consider the various architecture domains, they may have different forms.

As examples-

in Business Architecture, they could be the views of the Business stakeholders. The matrices between business strategy and the main business functions. The diagrams showing the relationship between processes and information. The Value Chains. Business and Operating models of the Enterprise. Customizing the configuration of the Business Functions according to model --- and more.

The artifacts for Data or Information architecture may refer to an information map or diagram . It could also show the mapping between data items and the Business Information map.

Artifacts for Application Architecture, could show the key interconnections between applications, middleware connection matrices. There may also exists views for Portal Architecture, Enterprise Content Management , Identity management, Business Intelligence, ERPs and CRMs.

Last but not least, Technology Architecture artifacts may propose servers and storage technology diagrams, office views (file, printing, data base servers, etc...), LAN/WAN/Voice Network architecture diagrams, applications and interconnections mapping to technology servers and networks, infrastructure security diagrams. In addition to that, there may be a certain numbers of artifacts related to the company’s organization, organization chart, lines of business mapping to business functions, organization roles in organization units and job descriptions.

Many graphical tools may aid to develop diagrams or document matrices but may also be quite costly. The use of spreadsheet may be a first step in building artifacts such as matrices. The following examples illustrate how they may simply be build with Excel.

List of Metadata

Data-Business process matrix

Application Inventory List

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.