Critical Enterprise Architecture netcast

Up to now enterprise architecture has been wonderfully or sadly (depends) free of review or auditing. But given the market pressure this will change. What will or how are audits in enterprise architecture look like? Will the enterprise architecture be in the form of an official audit or in a more informal process? Is it best to offer preventative documentation or should I wait for the formal audit? For those 3 questions it really depends who is conducting the audit. The most likely groups are: Architecture Manager, CTO or Chief Architect CIO or his representative Finance Internal Audit Peers or other architects Head of development or technical team Project Management or Portfolio Management External enterprise architecture consultants

In this netcast we will concentrate on all of the skills that an enterprise architect needs that are outside of the normal enterprise architecture. The skill set that I am focus in this netcast are: IT Key Cross Skills Other Key Cross Skills Other Important Cross Skills Other Useful Cross Skills After an introduction why cross skills are important and why they are usually not mentioned I will then visit all the skills on an individual base. IT Key Cross Skills Project Management Portfolio Management Change Management Service Management or operations Test Management Management of technical and development Areas Other Key Cross Skills Leadership, generic management Accountant (GL, Management Accountancy Cost Accountancy) Risk Management Critical Thinking Other Important Cross Skills Marketing (also as a main source for change in the future) Sales Pre-sales Legal Technical Writing Other Useful Cross Skills Operations (may vary what that means) HR Facility Management Supply Chain

Most TCO calculators will turn it in the favour of a product that's why you need to do the TCO as the enterprise architect. But is that not the job of the project manager or accountant? Rough guide what costs we will cover in this shorter than usual netcast Costs (lease or buy) in IT (always on 1, 3 and 5 years at least for trend, dependant on annual depreciation) Hardware (Desktops, Servers, Network devices, Racks, Server room cooling, LTO, Generator, Batteries,...) both separate or part of a shared environment Consumables (Tapes, Power, HDD,..) Software Licenses annual maintenance cost for software and/or hardware Staff Costs Contractor costs Consultants Operations (help desk, 2nd 3rd line, System Network Administration, Training,..) Overhead (usually add 30 %) Project costs (Initiation (with feasibility), Enterprise Architecture, Build, Test, Transition) Documentation Comms (LAN, WAN, Telephone,...) Unpredicted downtime ( not OoH) How do I get the costs Is this really useful? How do I use this. Should I not get consultants in to this?

As far as the joke goes: With a terrorist you can negotiate This net-cast will focus on the stakeholder to an enterprise architect and look how the enterprise architect can best manage his relationship without being seen as the most difficult person in the organisation. The stakeholders are (the list is not in order of importance): The customer The business owner The CIO The CFO or his/her representative (accountant) The head of programme-, portfolio- or project management The head of architecture (usually your boss) The head of service management or operations The head of PMO The strategy group of the organisations Various Board members on approval boards The head of development The project / programme manager in the project you are just engaged Part 2 The business analysts The project support staff  in the project you are just engaged The fellow enterprise architects The solutions- and technical architects The designers The head of testing The developers / Configurators The service designer The DBA The security officer The users

As far as the joke goes: With a terorist you can negotiate This net-cast will focus on the stakeholder to an enterprise architect and look how the enterprise architect can best manage his relationship without being seen as the most difficult person in the organisation. The stakeholders are (the list is not in order of importance): The customer The business owner The CIO The CFO or his/her representative (accountant) The head of programme-, portfolio- or project management The head of architecture (usually your boss) The head of service management or operations The head of PMO The strategy group of the organisations Various Board members on approval boards The head of development The project / programme manager in the project you are just engaged Part 2 The business analysts The project support staff  in the project you are just engaged The fellow enterprise architects The solutions- and technical architects The designers The head of testing The developers / Configurators The service designer The DBA The security officer The users

EA Certification comes in 4 flavours (this is my subjective view): Workshops and Reference checking schemes Frameworks Certification Money making shemes (that is money making for the provider not for the EA) Vendor specific schemes I will then look a bit closer on each of the categories and provide my own evaluation on the them. Frameworks (usually short lived and full of complexity) [examples: DoDAF Federal Enterprise Architecture(FEA) Allstate Architecture Standards and Methods (AASM) BearingPoint Configure To Fit Method BearingPoint Methodology Bredemeyer VAP CA Solution Architecture Methodology Capgemini Integrated Architecture Framework (IAF) Credit Suisse IT Solution Framework EDS GSMS/GAD QMS GM System Delivery Process (SDP) HP Global Method for IT Strategy and Architecture (HPGM for ITSA) IBM Global Services Method IBM TeAMethod Intel AEPF Intel IT Architecture Development Methodology (Intel IADM) New Zealand Inland Revenue - IR Method Raytheon Enterprise Architecture Process (REAP) TOGAF 7 TOGAF 8 TOGAF 9    (soon) Zachman ] Money making schemes (that is money making for the provider not for the EA) [examples: Enterprise Architecture (EA) Boot Camps 5000$ for 5 days just of framework manual Enterprise Architecture Offshore Training ] Workshops and Reference checking schemes (usually very expensive) [examples: FEAC Institute The Enterprise Architecture Center of Excellence (EACOE) ITAC ] Vendor specific schemes (EA specific on one product) [examples: Sun Certified Enterprise Architect (SCEA) Enterprise Architecture Certification Program, offered by IBM SAP Enterprise Architect Certification ] Alternatives that we need to look for: Just training (need to be critical) Professional non profit bodies like IEEE Certification body with a proper EA curiculum with a credit system (credits can be earned by courses of ideally different training providers and cover all the areas that inface with EA, e.g. Service operation, business analysis, project management,..) EA user group Master degree in EA But all them need to be geared on 3 basic principles: Reduce risk, save costs and cut complexity. They all need to be endorsed by non architectural bodies, such as in project managers or service managers

In this netcast I will describe how you can start building the first steps for a IT strategy without getting lost in the details. In my experience an entire IT strategy is almost impossible to build of from stratch. Usually this is because there is little of strategy from other areas and if you are building a strategy you first need a quick win, before geeting the budget for the whole work. A first step is to build a list of IT and service management principles, as it when they are agreed it is so much easier to start the proper work of a strategy because first you have already delivered something and second you can build upon that is agrred so that if you enter in discusions with stakeholders you can always refer to them as extensions to the original work. In my experience I will just give you my usual suspects and explain them. All of them are comming together with an Outline, a rationale and possible implication that I will give in the necast itself (as I do not know your orginasation I have to generalize): The Business Alignment Principle The Scalability Principle The Security Principle The Customer Viewpoint Principle The Business Ownership Principle The Business Continuity Principle The Interoperability Principle Information Is an Enterprise Asset Architecture Compliance Management Re-use before Buying, Buy before Building The Commonality Principle The International principle In the same way for the service management priciples The Service Transition Principle The Service Operation Principle The Continuous Service Improvement Principle The Service Level Principle

The Critical Enterprise Architecture netcast is a vendor neutral broadcast that focuses on best practices in Enterprise Architecture.

This netcast may actually a bit more thought provoking than the usual ones and I may seriously anoy some people. First I will explain that a picture is not an architecture Then I will show that the usual concept of an enterprise architecture documentation that follows something like this: 1. Executive Summary 2. Scope 3. Strategy 4. Requirements 5. High Level Architecture 6. Low level Architecture 7. Risk, Issues Assumptions 8. Appendix is inadequate, even if it so much better than the usual junk produced by many architects. I will then show that Enterprise Architecture documentation is really about the full design phase starting with requirements as follows: 1. The scope, the context or the requirements 2. The enterprise model, the concept or the business architecture 3. The system model, the logical model or the solution architecture 4. The technology, the physical model or the design phase 5. Detailed representations, out of context description or the implementation and build model 6. The the everyday, the service management transition or the service design Not every phase may be delivered by the enterprise architect, but he/she is certainly responsible. Additional there is another dimension in all of this that is to be considered into for all of the 6 phases, these are: 1. The data 2. The function 3. The network 4. The people 5. The time 6. The motivation I will then show how they are all important for the overall enterprise architecture documentation. Finally, if I still have listeners ;-) I will then describe how this all fits 36 nice little chapters and how to split them into single documents.

In this episode I will discuss the following architectural forces: Management of Requirements (not Functionality) Management of Performance and Capacity Management of Complexity Management of Change (Project, Service Management Business) Management of  Resources (People, Hardware, Software and Facilities) Management of Service Transition and Service Design Additional there is a small piece on what to do if no one listens to me as an architec

Instead of beginning this technical podcast on frameworks or technology, I have chosen to start this podcast on the essentials and on the pitfalls of Architecture. So the 7 Virtues of architecture are: Create an architecture for the strategic business needs Try to architect something with more than than 1 year or less than 3 years in mind Always keep the costs low. Costs should be calculated for 3 to 5 years Minimize risks wherever possible Use critical thinking all the time Create an architecture that is open for change as there is nothing as certain as change Assumptions are your friend The 7 Sins of architecture are: Haste Apathy Narrow−Mindedness Sloth Intellectual greed Ignorance Pride In the podcast I will discuss them more in detail how they apply to architectur