Enterprise Architecture

Aligning ITIL V3 Service Design with TOGAF 9

by

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!

Counting Down to Book Launch

by

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

Modeling the MDM Blueprint – Part II

by

In part I of this series we discussed what essential elements should be included in a MDM blueprint. The important thing to remember is the MDM is a business project that requires establishing of a common set of models that can be referenced independent of the technical infrastructure or patterns you plan on using. The blueprint […]

ERP for IT

by

Sometimes it seems like we’ve automated the business but not the IT world. Although some organisations have a plethora of systems and processes to manage the operational environments, governance, portfolios, architecture and projects most do not. …

Who would be a good Enterprise Architect?

by

Who would make a good Enterprise Architect? This is a question I get from time to time and it’s not an easy one to answer, mainly because the definition of an Enterprise Architect and the expectations of the role varies from organisation to organisation. Just taking a look at two articles that describe the EA role and it’s easy to see why many people want an answer to the question.

An enterprise architect requires a unique blend of skills. At various times he or she needs to employ the characteristics of an artist, a guru, a coach, and a spy. As an artist, an enterprise architect needs to be creative by looking beyond the “right” answers to uncover new solutions to old problems. The enterprise architect also needs to be a guru—someone who understands some topics in depth, but can address a breadth of business and technical topics.
 
As a coach, the enterprise architect must bridge both business and technology, be able to find points of influence in both camps, and ensure that technology stays off the critical path. Finally, as a spy, the enterprise architect must be able to work across the enterprise, see patterns across disparate business needs, and define solutions that satisfy multiple business needs. Enterprise architects grow from within the technical architecture ranks, learning how to be artists, gurus, coaches, and spies as they work their way from being technical specialists, through application or infrastructure architects, eventually to enterprise architects.

From my earlier posts you would also guess that I would add salesperson to the list. So where do you find people that fit this profile and understand all the technology aspects that are a pre-requisit? I don’t have the answer, but I do  know some assumptions I’ve seen in the past are not always right.

Assumption 1 – there is a clear career path from developer/analyst through project architect then to an applications or infrastructure architect role and finally to the EA role.

Assumption 2 – an EA is fundamentally a technical role.

I don’t believe an EA is fundamentally a technical role. It does need someone who really understands the IT environment, in applications, technology, infrastructure and operations but it also needs someone who understands the business activities and how to align the two. This is where I believe there is a discontinuity in the career development plans many organisations have that are based on assumption 1.

So who would make a good enterprise architect? Someone who’s had the experience described in assumption 1 and also has had to work well outside the IT comfort zone. This could be a secondment into a business team, working for IT suppliers on sales solutions or consulting roles which broaden perspectives.

Recommended readings

by

 

    All the good intentions to write this blog fall apart if I keep cancelling the daily reminder to put something in. Today I was spurred back into action by someone mentioning they had started to read it (Jon you’re the spark today!) – now that’s not going to take long I thought, so time to post some more.

     

    This all started because of a presentation at a conference last week – I’ve been asked many times since then for a reminder of the key book recommendations for further reading. Before I list them here’s a little insight into why I recommend them. Firstly, these are to my mind some of the key non-technical subjects that enterprise architects need to be proficient with. I’ll go further and say it’s subjects like these that separate the system /infomation/ technology architect from the enterprise architect role. I did say ‘some’ of the subjects and in future postings I’ll get to the rest (but you won’t find many technical entries!)

     

    There are many postings on the internet which attempt to define the EA role, probably with as many variations as there are EA positions. I liked this  as I browsed the list thrown up at www. live-com. I’m going to partially define the role by example of one of the roles the Enterprise Architect takes on-chief salesperson for the EA work. And with that definition back to the books which help the EA create the ‘sales materials’ and go about selling them. 

     

  1. “Enterprise architecture as strategy” by Jeanne W. Ross, Peter Weill, David C. Robertson
  2. “Beautiful evidence”, Edward Tufte
  3. “Hope is not a strategy”, Rick Page

    4.  

    So now I’d better justify this selection. Jeanne Ross et al do a great job with real evidence to show how to take Enterprise Architecture work to the top table and clearly show it as the IT strategy. One of my favourite mechanisms for doing just this is the creation of a one page view that links all the critical pieces together. If ever thought I would write the book on this approach I’ve given up the idea now. Just buy this one and do it. My one criticism is that the examples used are a little simple, they give all the right ideas but one fell example world be great. I speak from personal experience here- my audience at the conference wanted more real-world examples. the problem is these usually contain a lot of company details which people don’t want to shave. But having said that I’m going to try & create some generic versions now.

     

    When it comes to putting the information on a page the master is Tufte. The 6 principles he describes in his new book should become the mantras for effective EA communication. One of his other points I’m going to throw in now comes from his thinking on the shuttle disaster. There are a number of points to draw from the analysis but the one I will highlight is that splitting information down into individual entities and then presenting them does not allow the audience to easily work out the relationships and the consequences. In EA terms the entities are necessary to have enough detail in the decomposition to fully define processes, applications, information and technology but you cannot present them independently (or even in small groups) to describe the architecture – a good description of an EA might well include business, information, application and technology all on one page linked with justifications, strategic direction, opportunity, timelines and benefits!

     

    Hope is not a strategy is a good book out of the many that are available to describe the sales process for complex sales (responding to RFPs, developing demand etc). Why is this important to the enterprise architect? Because the architect has to sell the architecture to people in IT and importantly across the whole business. But they have competition -every sales team that turns up, well prepared, with a solution that fits the business need, regardless of how it fits with the architecture plan. So the enterprise architect needs to be a salesperson and that means having the having the materials, processes and information that sales teams work with. More on this in a future blog and also in the conference materials.

     

    The conference papers have all been posted http://www.microsoft.com/uk/msdn/architecture/architectinsight/2007download.mspx and you can access the worksheet I used here http://download.microsoft.com/documents/uk/msdn/architecture/architectinsight/2007/Enterprise/ENT06-Creating-Core-EA-Diagrams.pdf