10 years, 8 days ago

More than trends

A colleague at Microsoft, J.D.Meier, recently wrote a blog post about the major trends to watch for in 2010. Rather than creating just a new list he’s provided all the source material references which make it ideal to use for personal research and to take a unique filter for your own organization.

What really struck me in reading this was the last section, which is less about trends and really about what each of us needs to consider to be relevant and at our most effective in the coming decade and I’ve repeated it here:

  • Build a firm foundation.  Know Maslow’s hierarchy and prioritize taking care of your basic needs.  Know your “monthly burn” and be mindful of your decisions to support your firm foundation.  The stronger your foundation is, the more you can help yourself and others when they need it most.
  • If it doesn’t help you be your best, cut it out.   This means living your values, and playing to your strengths.  It also means giving your best where you have your best to give, as a person, and as a company.  It’s how your survive, and it’s how you go from surviving to thriving.   Any other way drains you in the long run and you get priced or pushed or competed out of the market.  It’s the sustainable path. 
  • Follow the growth.  Follow your own growth, and follow the growth in the market.  For example, in the tech industry some growth areas are mobile and cloud.  Along these lines, create the growth.
  • Get back to the basics.  Practice the fundamentals.  They work.  Among the chaos, there are always core principles, patterns, and practices that you can bank on.
  • Hone your personal brand.  Make the most of what you’ve got and make sure your differentiation is obvious.  For example, one of my differentiators is “getting results.”
  • Invest in yourself.  Inner-engineering always pays off.
  • It’s your network and what you know.  People sort and sift through people they know.  In a skills-for-hire economy, your network is how you find the opportunities. 
  • Know the cycles of things.  For example, know the Four Stages of Market Maturity, the Technology Adoption Life Cycle, and the Diffusion of Innovations.
  • Lead yourself from the inside out.   Follow your values, play to your strengths, and follow your purpose.  It’s the sustainable path.
  • Learn and respond.  Your ability to learn and respond will drive your best results.  Innovate in your process and your product.
  • Look ahead.  Build your anticipation skills.  Know the system.  Things don’t just happen.  The more you know the system and the ecosystem, the more you can anticipate what’s coming down the line.  Pay attention to market leaders, trend setters, patterns, and cycles.  Everything happens in cycles whether it’s growth or decline.

All too often we have work commitments and development plans that are focused on the near-term, possibly as short as the next quarter. But as we see continuous change becoming the new normal I thought these were fine words to reflect on, and practical steps for how we should think about surviving the long term.


10 years, 14 days 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.

10 years, 1 month 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.

10 years, 3 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.

10 years, 4 months ago

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.

10 years, 4 months ago

Prioritizing the portfolio of IT projects

One of the common activities for IT departments when times get tough is to review the projects underways and see where greater prioritization mught realize benefits faster and re-focus resources. I recently wrote a paper for the Architecture Journal wi…

10 years, 6 months ago

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