In an previous post, I wrote about the difference between the application of technology to the building of products, vs the application of technology in running the business. They are pretty different animals, if nothing else because of the way they a…

This has been a great week, for several reason, but most notably because our book, Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance, is now in AuthorHouse’s hands and should be ready for ordering very soon. On the book’s website, we have published the Table of Contents and a chapter overview, and also

I am collecting humerous terms for different kinds of integration. I will seed the discussion with a few, but would be interested in having others added, with descriptions in the comments to this posts. It would be delightful to have a large glossary o…

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).

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).

This post arises from conversations (over many years) with John Hall, the late Keith Robinson, Bob Brown, Keri Healy, Nigel Green, Richard Veryard and Fred Fickling. It has to do with how we identify things, immutability and most recently REST. So firs…

This article (Can SOA Give You Good Service) identifies some of the troubles withwords when dealing with all the Service terms. I found it a very helpful article indeed because it helps keep Service and SOA on the straight and narrow. Nice call out of …

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…).

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…).

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.

In this series we have discussed developing the MDM blueprint by creating Common Information (part II), Canonical (part III), and Operating (part IV) models in our work streams. We have introduced the Operating Model into the mix to communicate how the solution will be adopted and used to realize the benefits we expect with the […]