Posted on

Reasons for ITIL Implementation Failure

1. You treated it as an implementation.
ITIL is not something you implement, it is not a standard. It is a set of best practices that you can integrate into the unique properties of your IT organization.

2. You hadn’t already evaluated your existing processes.
ITIL isn’t simply going to solve all your problems. There are two key components of any organizational improvement, and that is process improvement and the ability of people to change or adapt to change.

3. You didn’t spend enough time getting people on board.
This could be hit or miss, but it is more likely to miss if you simply sent a team out to make the changes, and did not directly include the people affected by the changes. Work done on bringing people over to the new initiative, especially those passive resistors, early and throughout the process, will pay handsomely in a projects success.

4. You picked areas of ITIL that didn’t demonstrate ROI immediately.
Some areas of IT Service Management are more reactive to change from best practices like ITIL. For Example, looking at Service Desk, Change Management, or Self Service improvements, will tend to have immediate results, and are highly influenced by automation. If you are looking to get buy-in for longer-term projects, start with these areas and then move outward. Once an organization can see impact from ITIL, future projects will be easier to get everyone on board.

5. You approached ITIL and its various components subjectively.
Whatever emotions and previous experiences (failures or successes) you take with you into applying ITIL concepts and best practices will cause pain. Like everything else, look at the big picture, and be as objective as possible.

6. You placed too little importance on your ITSM solution.
Your ITSM solution is the CPU of your IT organization. If it’s bogged down, or unable to change and move at the speed of the new processes, ITIL may not help. Again, take a step back and see how your goals line up with the abilities of your tool. Of course, we’d love for you to take a look at ChangeGear, built with ITIL best practices in mind, out of the box.

7. You focused on ITIL as a goal that has a finish line.
ITIL tends to work best as an iterative process with continuous service improvement. So, in a manner of speaking, you will never be finished with ITIL, that is if you plan on it being a successful part of your IT organizational philosophy.

8. You compartmentalized the benefits to IT and/or technology.
The entire organization, not just IT should see benefits, and thus should understand that changes will be occurring and will likely impact the business as a whole. Besides, with the modern metamorphosis of the IT department, ITIL can fit nicely into the other technology initiatives already happening around the organization.

9. You tried to improve too many areas at once.
There are no rules to adopting ITIL best practices. This is your organization. You can do as little or as much as you want. Stephen’s blog highlights some of the best and most common places to start, which is probably a good idea. Just stick with the idea that boiling the ocean tends to lead to failure, or at least a lot of unhappy beach goers.

10. You ignored the influence of, and impact to, culture.
Your organization is unique. Before implementing anything, take a step back and look at how it approaches change, and how it may be affected by change. Understanding the culture you will be working within, might just change a failure to a success.

Posted on

Role Conflicts and Synergies during implementation of ITIL

Complete ITIL implementation will bring around 40 new roles to organizations but it is not practical to do so even for a big organizations. The reason is that some processes are not best suited for the existing structure, and that the cost of change will perhaps exceed the selective process selection and unnecessary increase the cost of implementation without adding any value.

While larger enterprises boast of a good chunk of ITIL roles manned by dedicated resources, smaller organizations (if they end up implementing processes in service design, transition and operation), might choose to go in for the full array of roles, with resources handling multiple roles concurrently. Having dedicated resources requires deep pockets, and a bottomless pit of budget reserves, which is unusual these days.

ITIL publications do not explicitly talk about people holding either a single role or multiple roles. But the implication is that a person will take over one role, and not multiple ones.

There are three different categories for the combination of role: conflicting roles, roles with synergy and roles which does not care about conflicts or synergy.

In ITIL, if the outcome of one role is influenced negatively by the other, it qualifies as a conflict. Or, if the objective of one role has elements that tend to alter the thinking of the other – now that’s a conflict. 

The combination of two or more roles which ends up benefiting one or multiple processes. A producer, who also directs the movie, is more likely to optimize spending and sweat over all directorial details to ensure box office success. Whether it succeeds or tanks is different topic to discuss another day.

There are a number of role combinations which falls under don’t-cares. They neither conflict, nor add synergy. 

ITIL roles that conflict

Incident and Problem Manager

This is a classic role conflict in ITIL. Many organizations identify the same person to do both the roles without realizing what is at stake.

An incident manager’s objective is to drive toward resolution at the earliest–either through a temporary workaround, or a permanent solution if available. A problem manager is hell-bent on getting to the root of the problem. He’s interested in the source of the problem, and unless and until a permanent solution is not in sight, he doesn’t care about any temporary fixes.

In theory, and in practice, it’s pretty obvious that both the roles require people who are oriented quite differently. Yet it’s a common practice to club these two conflicting roles.

Release Manager and Service Test Manager

A release manager has an objective to release software or implement hardware equipment as per customer requirements/architecture. In PMI methodology, he would be called a project manager, as the activities involved are similar, i.e., initiation, planning, execution, control and closure.

One of the sub-activities of release management is testing the release package before it’s deployed. A service test manager is appointed to oversee the test activities and report on the observations found.

It’s not uncommon to see a release manager being given the responsibilities to manage build, test and deploy activities. I have a problem when a release manager works as a test manager as well.

The test manager’s job profile includes testing the built package, verifying if the functionalities are as per design and whether the release meets customer expectations. Whereas a release manager wants to complete the project on time–and within budget as always.

If the two roles are combined, there is every chance that the test manager’s role can be compromised. Suppose the release is running on a tight schedule, and a minor flaw is identified which may not impact anything directly. A test manager who is also a release manager might overlook it for the benefit of the other role he’s playing.

In all activities, a tester must be a different person. In ITIL, another popular conflict on the same lines is the process manager playing the role of a lead auditor. This should not be allowed, for the organization’s own good.

Process and Service Owner

A process owner owns the process (like incident management), and is responsible for ensuring that it’s fit for purpose intended. A service owner likewise owns the service but is responsible for the delivery.

This conflict is rather indirect. A process owner, who owns the service as well, is adapted involuntarily to the service he owns, and to a certain extent, starts looking at services through the lens of the service he owns.

Being a process owner, his scope extends to other services that he may not own. So, when he tries to apply the process to another service whose genetics are quite different, it may feel like tailoring a suit for Kevin James, and asking Johnny Depp to don it.

 

ITIL roles that synergize

As I mentioned earlier, the combination of two or more synergistic roles benefits the other.

Risk and IT Service Continuity Manager

A risk manager is tasked with identifying, assessing and controlling risks. An IT service continuity manager ensures the service is able to perform at minimum service levels if a disaster happens.

Both the roles are aligned, in the sense that they are proactive, but they also look toward the future, getting ready to minimize the unintended effects.

Each would help the other in contributing with specific intel that helps both the process overall.

Configuration and Knowledge Manager

A configuration manager identifies, records, controls and verifies records of configuration items. A knowledge manager does a similar set of activities with available information, and knowledge.

Knowledge management is relatively new to many organizations, but configuration management has existed for a while. However, a knowledge manager need not re-invent the wheel to plan the management of information and knowledge.

In this case, configuration management can lend a hand, and synergize knowledge management activities for the better.

Posted on

BEFORE: ITIL Implementation

There is one certain way that leads to fiasco – to start implementation of the entire ITIL framework. It sounds funny, but there are 26 processes and 4 functions in ITIL. To start implementing all (or most) of them… is not at all a good idea.

There are many things you need to consider before deciding which part(s) of ITIL you are going to implement. Here are some generic issues which are very important to consider.

Business Process Management – IT processes have to be aligned with business processes; i.e., IT services have to underpin business services. That means that there is no point in implementing an IT service if the business does not have a need for it. I remember a situation where IT implemented an internal employee portal, which was supposed to integrate all employee-related information and services (e.g., salary data, presence/absence from work, education records and training management, traveling service…etc.), but other departments inside the organization (HR, Finance…) were not properly involved in the project and, consequently, were not motivated to be a part of the service.

Standpoint – It’s very seldom that you are starting from scratch, i.e., that you don’t have any process in place. Maybe they are in chaos, but more than likely you have some processes in place and you need to do something to get them under control, improve them or introduce some additional processes. Before you finish your To-Do list, perform the gap analysis and see how far (or near) to the ITIL recommendations you are. If you have an ITSM tool in place – your “maneuvering space” is usually limited. The reason for that is that tools are customizable to a certain extent (from my experience, level of customization is proportional to the cost of the tool). Don’t forget to consider “pain points” (e.g., those processes which are causing most of the problems, delays, errors…) and “quick-wins” (something that you can implement in a short period of time and show immediate benefit).

Drivers – are you clear on what the drivers are for the implementation? Is it poor customer support emphasized by customer complaints? Or your company is growing and IT (and the services) are gaining in complexity, so you need a “tool” to manage them? Maybe you need better coordination of daily activities in a multi-team environment (and you want to manage the work and not vice-versa)? Whatever the reason is, it’s important that you are clear about it. Namely, it will define your goals, project, resources… etc.

Resources and Management support – when you gain your management’s approval, doors to your resources are open. That’s important because you are, probably, not the only resource in the story. You need some financial resources, other people (either to help you during implementation or as process owners once when you finish), external parties, tools… etc. I had a customer that wanted to consolidate two existing Service Desks and implement several ITIL processes. The idea was excellent, and preparation was done well, but the approach to management was wrong. The implementation project did not take place.

Depending on your organization – think about your issues before you approach management to get approval (e.g., if you are part of an international organization, most probably many things are already pre-defined).

Posted on

Important Points When Using Statements of Applicability (SOAs): ISO 27001

  • Organizations should identity all control objectives and actual controls selected for implementation when completing the SOA.
  • The SOA doesn’t need to contain confidential asset and process information.
  • Controls in addition to those stated in the standard may also be stated as part of the SOA.
  • Any ISO 27001 controls that are not selected for compliance must be explained.
Posted on

Determining Maturity Levels before implementing ISO 27001

When assessing the organization’s compliance maturity level, auditors should determine whether or not the implementation team is able to answer the following questions:​

  • ​​Does a document exist that specifies the scope of compliance?
  • According to ISO 27001, a scope document is required when planning the standard’s implementation. The document must list all the business processes, facilities, and technologies available within the organization, along with the types of information within the ISMS. When identifying the scope of compliance, companies must clearly define the dependencies and interfaces between the organization and external entities.
  • Are business processes and information flows clearly defined and documented?
  • Answering this question helps to determine the information assets within the scope of compliance and their importance, as well as to design a proper set of controls to protect information as it is stored, processed, and transmitted across various departments and business units.
  • Does a list of information assets exist? Is it current?
  • All assets that may affect the organization’s security should be included in an information asset list. Information assets typically include software, hardware, documents, reports, databases, applications, and application owners. A structured list must be maintained that includes individual assets or asset groups available within the company, their location, use, and owner. The list should be updated regularly to ensure accurate information is reviewed during the compliance certification process.
  • How are information assets classified?
  • Information assets must be classified based on their importance to the organization and level of impact, and whether their confidentiality, availability, and integrity could be compromised.
  • Is a high-level security policy in place?
  • Critical to implementing an information security standard is a detailed security policy. The policy must clearly convey management’s commitment to protecting information and establish the business’ overall security framework and sense of direction. It should also identify all security risks, how they will be managed, and the criteria needed to evaluate risks.
  • Has the organization implemented a risk assessment process?
  • A thorough risk assessment exercise must be conducted that takes into account the value and vulnerabilities of corporate IT assets, the internal processes and external threats that could exploit these vulnerabilities, and the probability of each threat. If a risk assessment methodology is in place, the standard recommends that organizations continue using this methodology.
  • Is a controls’ list available?
  • Necessary controls should be identified based on risk assessment information and the organization’s overall approach for mitigating risk. Selected controls should then be mapped to Annex A of the standard — which identifies 133 controls divided in 11 domains — to complete a statement of applicability (SOA) form. A full review of Annex A acts as a monitoring mechanism to identify whether any control areas have been missed in the compliance planning process.
  • Are security procedures documented and implemented?
  • Steps must be taken to maintain a structured set of documents detailing all IT security procedures, which must be documented and monitored to ensure they are implemented according to established security policies.
  • Is there a business continuity (BC) management process in place?
  • A management process must be in place that defines the company’s overall BC framework. A detailed business impact analysis based on the BC plan should be drafted and tested and updated periodically.
  • Has the company implemented a security awareness program?
  • Planning and documentation efforts should be accompanied by a proper IT security awareness program so that all employees receive training on information security requirements.
  • Was an internal audit conducted?
  • An internal audit must be conducted to ensure compliance with the standard and adherence to the organization’s security policies and procedures.
  • Was a gap analysis conducted?
  • Another important parameter to determine is the organization’s level of compliance with the 133 controls in the standard. A gap analysis helps organizations link appropriate controls with the relevant business unit and can take place during any stage of the compliance process. Many organizations conduct the gap analysis at the beginning of the compliance process to determine the company’s maturity level.
  • Were corrective and preventive actions identified and implemented?
  • The standard adheres to the Plan-Do-Check-Act” (PDCA) cycle (PDF, 62KB) to help the organization know how far and how well it has progressed along this cycle. This directly influences the time and cost estimates to achieve compliance. To complete the PDCA cycle, the gaps identified in the internal audit must be addressed by identifying the corrective and preventive controls needed and the company’s compliance based on the gap analysis.
  • Are there mechanisms in place to measure control effectiveness?
  • Measuring control effectiveness is one of the latest changes to the standard. According to ISO 27001, organizations must institute metrics to measure the effectiveness of the controls and produce comparable and reproducible results.
  • Is there a management review of the risk assessment and risk treatment plans?
  • Risk assessments and risk treatment plans must be reviewed at planned intervals at least annually as part of the organization’s ISMS management review.
Posted on

Tips for ISO 27001 Imlementation

1. Decision

Senior management need to be behind the decision for ISO 27001 certification. There is definite value in communicating this internally, it enforces the company’s aspiration to pursue best practice.

What is needed? Concise and positive briefing to senior management outlining benefits and how it provides a platform for business growth.

2. ISO Management Representative

The company appoints a responsible and knowledgeable manager to run the programme and implementation. This person will become the company’s ISO 27001 specialist, understanding the controls and milestones needed towards accreditation.

What is needed? Selection of the right individual with a specific job description and knowledge of ISO and ISMS requirements.

3. Gap Analysis and Risk Assessment

An assessment of risk or a gap analysis is conducted to find out what can go wrong and which threats endanger the Confidentiality, Integrity and Availability of information. This is to understand the maturity of existing controls within the business and to determine the risk profile.

What is needed? The gap analysis followed by a risk assessment of all in scope people, processes and technology performed by a qualified auditor. Understanding the maturity of controls and risk profile.

4. Scope & Implementation Plan

The review of output from the gap analysis allows the business to validate the scope of implementation and the functional / operational boundaries. For each risk identified, appropriate controls are set to manage the risk in a systematic way. This will ensure nothing important is missed. Important milestones, time requirements, dates for any pre assessment and staged audits are set.

What is needed? A step by step concise guide to explain the ISO 27001 process in sufficient detail.

5. Employee Introduction

It is important to engage with employees from the beginning to ensure they buy in to the ISO 27001 certification process and respond appropriately. Also to help them to understand the individual, company and client benefits.

What is needed? A short and easy-to-understand ISO 27001 and security introduction briefing that focuses on how employees are affected and their role in the successful implementation.

6. ISO Documentation, documentation, documentation, documentation!

ISO 27001 certification requires extensive documentation addressing all relevant millstones and individual controls. This forms the criteria the company is measured against to meet the ISO standard.

What is needed? A set of policies, standards and procedures to ensure the business is adhering to all requirements in an efficient and achievable manner.

7. Realisation

With the gap analysis, scope and documentation ready, it is time to put new processes into ‘business as usual’ throughout the company to start realising the many benefits of ISO 27001. At this stage it would be beneficial to conduct a pre assessment to ensure the company is on the right track and validate the evidence.

What is needed? Pre assessments forms, checklists and the gathering of evidence. Communication to staff about the revised processes, the need to adopt them fully and report back on what isn’t working.

8. Internal ISO 27001 Audits

ISO 27001 requires an internal audit to assess where the company is at with the milestones and the implementation phase. An auditor will complete documentation assessing the risk, noting controls and remediation to highlight the improvements required.

What is needed? An experienced internal or external auditor. Audit tools that include forms, complete audit checklists and audit reports.

9. ISO 27001 Certification

The most important step is to pass the ISO 27001 certification audit. An independent assessor will issue a certificate stating that the business is meeting the ISO 27001 controls and requirements. The appointed internal representative needs to be confident with the process they have followed and consider how to best interact with the assessor.

What is needed? Employee preparation for the ISO 27001 certification including questions that may be asked and the areas the audit will focus on. An independent assessor from a reputable company.

10. Maintaining the ISO 27001 Certification

It is important to keep the ISO management system working by its integration into daily operations. The business should focus on continual improvement.

What is needed? A reinforcement message to employees. Focus on maintaining the standards through an internal champion. Treat it as integral component of the business processes and not a one off project.

Posted on

How to start ITIL Implementation in your organization? [Keep it Simple and Straightforward]

First step: you must create an opinion about the implementation project. Negative feelings about the project will decrease support and acceptance.

Waste of resources – starting in the wrong direction usually causes a loss of money. Take, for example, human resources that you use for implementation – you can always express them in monetary value, particularly for external ones (e.g., consultants that are hired on the project)

Credibility – your results build your credibility in both ways, positive as well as negative. Here, I mean both your credibility inside your organization as well as inside your own team.

It’s very important to start in the right way. You can find a lot of resources about ITIL implementation. But, you are the most critical factor. Why? It’s simple. You know your situation (i.e., motivation and trigger for implementation), your organization, your people, etc. Namely, the ITIL framework is wide and covers many aspects of IT. Therefore, you should find what is most important for you and your organization, and the issues you are trying to solve.

How to start?

Although every situation is its own story, there are a few points that are advisable to most of the implementation projects.

Efficient start of the implementation is essential.

Start smart – You created a list of the processes and functions that need to be implemented, and you start to implement them in sequence according to your own preference. Such implementations usually never end. Take the opposite approach. For example, create a To-do list with the complete scope of the implementation (all processes, i.e., functions). Assign priority to each one. Consider carefully which ones can be combined and implemented together (e.g., if you need to implement both, Change Management (CM) as well as Service Asset and Configuration Management (SACM), there is no point in implementing CM and then few month later SACM). But, be cautious. You can’t expect to be able to implement all (or many) of the processes, i.e., functions in the scope in parallel. Go step by step and combine when it is necessary

Quick wins – these are the goals that can be achieved quickly and “easily.” Detect quick wins and do them first. In such a way you will gain credibility and your project will defend the reasoning for implementation. In this way you will get much more “space” for the rest of the implementation. Pressure will be lower and, since it will be obvious that you deliver results, you won’t be under a magnifying glass. When providing quick wins, it usually happens that you are left to do your work, meaning that you can completely focus on the project. For example, your organization pays penalties because incidents are not resolved in the time defined by Service Level Agreement (SLA). By implementing Incident Management, you will gain control of your incidents and save money.

Project approach –ITIL implementations have all the features of a project (time, resources, goals, deliverables, costs, etc.) and there is no reason not to treat it that way. Quite the contrary, compared to ITIL, Project Management is much “older”; i.e., there are enough reliable project management methodologies that can be your powerful tool to bring the implementation to success.

Control and steer – Independent of scope, ITIL implementation is tricky. It goes deep into operating processes and influences the way people do their jobs, i.e., the way the organization works. Therefore, you have to be very careful and keep your steering wheel firmly in your hands. One of the tools you can use is measurement. Measure before you start the implementation and afterwards. Compare the results and you will know whether you are on the right track. Return on Investment (ROI) is another one. When you succeed in Incident Management implementation and achieve incident resolution within the target time, it will be easy to calculate ROI for that process (direct benefits are savings in penalties that are not paid, an intangible benefit is organization’s reputation in the eye of their customer, etc.).

Keep it Simple and Straightforward

Size of the organization, organization’s culture and setup, management, your own team, complexity of business and processes… there are many parameters that can influence and increase complexity of the implementation. On the other side, those parameters are quite often taken as an excuse.

There is a principle that can be used to explain approach to the ITIL implementation: KISS – Keep It Simple and Straightforward. Business life is complicated already, it shouldn’t get worse and topics which implementation covers should be addressed directly. There is enough know-how about ITIL and implementation. Use that know-how, take what is relevant to you and avoid unnecessary complexity. And, get started.

Posted on

Benefits of Enterprise Architecture

IT-related 

Complexity management: Facilitate the scoping and coordination of programs and information systems projects. Manage complexity and describe the interdependencies in a usable manner.

Technical resource oversight: Identify and remove redundancy.

Knowledge management: Manage and share knowledge modularly so it can be visualized across different levels.

IT visibility:  IT resources and systems are more aligned to business strategies and are better placed for responsiveness.

Business-related

Reduction in impact of staff turnover : Capture knowledge from employees and consultants.Provide business solutions from third party organizations consistently so they can conform to the current models.

Faster adaptability: Facilitate knowledge acquisition necessary for changing systems and adopting new components.

Operating procedures improvement: Understand and model business processes. Review and re-engineer processes.

Decision making: Represent an enterprise’s layers and components modularly to let the organization make business decisions in the context of a whole instead of a stand-alone part.

Posted on

Management Styles of Enterprise Architecture

Zachman’s   argument that you have to plan before you do and that you need a view across the whole enterprise is compelling. However, how much of a plan do you need and how much of a view do you need? The strategy of the organization should drive our efforts. The strategy will contain objectives, a statement of its appetite for risk, the timetable for achievement of the goals and the investment it is prepared to make. Architectural efforts must align and produce only the artifacts geared to strategy delivery. If the timescales are tight or money short, then we must be pragmatic and compromise.

However, what often happens is that the objective becomes populate the Zachman Framework for the entire enterprise. Each cell generates a task to create an “As-Is” model and a task to create a “To-Be” model. Each column is taken and given to an architect. The answer isn’t understood and there aren’t any standards for modeling strategy, so “best practice” becomes the guide for producing all the “To-Be” models. This isn’t arrogant, of course, because it is based on logic.

Transformational Architecture

Sometimes, the organization has a “big idea”, a transformation, a merger, a shared services structure, a major change of some sort that requires major investment in IT. The case for architecture is easy … Big change = big design = architecture.

A business transformation places “big architecture” in a clear context with clear objectives and timescales. It gives direction, visibility and urgency.

A major issue for architecture is keeping close enough to the business change to design a solution that meets the needs and has a feasible migration path. Get behind the curve and the consultants and vendors fill the vacuum with half baked solutions that you spend the next 5 years unraveling because they were poorly architected. Get too far ahead and you get accused of trying to bend the business to fit your own pet scheme. Highlight too many problems and you are seen to be “off message”.

How do you get involved? This comes down to influence, relationships and politics because you have no right to be there. Do some stakeholder analysis and plan a campaign to raise your profile in a sophisticated manner that gives credibility and influence as a business person who is worth listening to.

Project Architecture

The concept of an enterprise architect being controlled by a project is nonsense. The job title may include the word “architect” but it is not architecture if the project manager has control of the architect – role is actually a design role. A fundamental part of architecture is that architecting concerns balancing competing demands between projects, between long term and short term objectives, and between different areas of the enterprise. There is a conflict of interest if the project manager controls the architect.

Should architects be allocated to projects? Yes, but only when necessary. When is necessary? When the project may decisions, through pressure of objectives or through ignorance, that pose a significant threat to enterprise business goals. If there is no risk, then there is no need for architectural involvement.

In practice, there is always some risk. There are also constraints on resources, so risk drives the level of involvement required. A triage process is essential to identify up front where to put resources, and integrating architecture into the development process means that you should never lose a project.

Program Architecture
A transformation involves the whole business, doing transformational architecture is by definition enterprise scope. A program typically has a single business theme, e.g. customer service, which has a narrower scope and impact.

Program architecture is a mix between transformational involvement and project involvement. Architects work across the projects within the program to deliver program objectives. They also have a role to ensure that the program follows the enterprise agenda not the program agenda if it differs.

Portfolio Architecture

A program is a set of projects that are related at a business level and it is clear that there are significant inter-dependencies. A portfolio is a set of projects that are managed together for convenience, it may they share a resource pool or a set of business managers. But from a business point of view they are seen as largely independent.

The project management approach is typically to treat these projects as independent from a deliverable perspective but resource constrained. However, the reality is that they are likely to be using the same data, programs or infrastructure.

The architectural task is to carry out a technical impact analysis to understand where different projects hit the same IT asset. Databases and programs should be changed a minimum number of times to minimum costs and risk. Infrastructural changes need to planned as a single exercise to leverage shared infrastructure and to minimize procurement and implementation costs.

This puts timescale and resource constraints into the projects but it achieves greater quality and lower costs. You just have to persuade the project managers and the portfolio board of this.

Operational Architecture
Being service delivery oriented they have clearer and quicker paybacks. However, the skills base and interests of those typically in architecture roles often does not sit well with such an orientation.

An example of an operational architecture objective would be “reduce help desk calls”. If there are 10,000 calls a month and each call costs the IT function $25, then a 20% brings a cost benefit of $600,000 potentially realized by reducing IT headcount or reducing the need for contractors. The business benefit is much higher because each call is lost time to the organization which may mean increased operational costs or lost revenue. My team delivered this within 2 months by reviewing the use of the helpdesk system, implementing better solutions for frequent calls, and redesigning end to end processes. Was this IT focused? No, the organization gets an improved IT service which means it can use its resources to meet its objectives rather than to deal with IT problems.

Other examples could be:

  • identify and eliminate repeated problems
  • reduce release failures
  • reduce call outs
  • improve application performance
  • improve security
  • demise expensive platforms
  • improve business intelligence
  • speed up the turn around of small changes

Operational architecture is about getting IT’s house in order before pushing the business to do the same. It is about taking the medicine within IT before exposing the business to its rigors. It is about proving the value for money of an enterprise architecture team. It is about delivering tangible benefits to the organization in terms of improved IT service delivery and reduced IT costs. Six months of solid operational architecture performance gives credibility and a great foundation for extending the architectural objectives into the organization.

Procurement Oriented Architecture
Procurement oriented architecture focuses on the purchases that the IT function makes and attempts to optimize them from a financial point of view. Architects review application and infrastructure purchases.

With applications, reuse or extension of existing in house or licensed applications will typically be advised if possible. Minimizing the number of suppliers is also often a goal. The pitfalls are shoehorning needs into inappropriate applications and some suppliers terms have financial “steps” in them that make further licenses prohibitively expensive.

With infrastructure, consolidation is the key to minimizing costs which requires a good knowledge of capacity needs and actual performance. Infrastructure costs typically have financial “steps” which can be exploited. For example, my team saved $5M on an $8M proposal by changing the required spec from 3 top end servers to 5 mid range servers. Did the supplier like it? No. Did they offer the lower range solution? No. We had to do the detail to work out that our requirements could be met by the lower spec machines. The small amount of added complexity and marginally lower flexibility were not worth $5M.

Like operational architecture, this approach is largely confined to within IT but does have significant measurable benefits that can form a foundation for extending architectural work.

Policy Architecture
Architecture policies are the practical instructions for the implementation of architecture principles. They instruct those delivering applications and infrastructure on what they must deliver. They may also set out SLAs or contracts with the business e.g. for data quality.

Some architecture departments’ primary mode of governance of the IT function in relation to architecture policies. This is the creation and maintenance of policies, guidance on policies, policing the process, approving documents, issuing waivers, etc.

This is a very dry role. There is creativity in the research the goes into the formulation of a policy. There is human interaction in the dissemination and mentoring that goes into supporting policies. But often, the architecture function slips either into a police force or to a burdensome bureaucracy.

Sometimes this model is imposed, for example, by the group company on a subsidiary. In this case, efforts must be made to make the approach user-friendly. Architects should guide and support projects so that they automatically comply. They should identify the need for a waiver early and sponsor it. Project managers need to understand the impact of compliance on their projects so that their estimates take any adverse impacts into account. The rationale behind policies should be explained.

Model Based Architecture
The aim of model based architecture is to create models in the hope that they will prove useful. Unfortunately, the usage is often not clearly defined. This means that the models don’t have a real purpose, they don’t have an audience. The result is that they are not built to be used. They become write only models.

Models are tools for architects to do their jobs working with business and IT management and staff to achieve benefits for the organization in line with the objectives of the organization. Models are not an end in themselves.

Silo Based Architecture
A pet hate of mine is to divide architects into business architects, technical architects, data architects, infrastructure architects, solution architects, project architects, etc. It creates silos where the architectures don’t connect.

The application direction is intimately related to the process direction and the data direction and the infrastructure. We can’t pretend that they independent and set up different teams to work on each area separately.

Architects obviously have competencies and preferences in different areas but they must be able to operate competently across all domains otherwise they are not architects.

Another type of silo based architecture organization is to align with the business unit structure. This can result in architecture reinforcing business silos and fundamentally failing to support the enterprise agenda.

How do I organize? I operate a very fluid and flexible structure. I have two tier teams. One tier is the more experienced architects who are capable of running an initiative. Some of the architects have ongoing roles as single points of contact. The rest of the architects form the other tier.

I continually form and reform teams to address specific needs typically the structure changes every few weeks. Each person is generally in 2 or 3 teams simultaneously. Sometimes the teams include people from the business or from other IT areas.

My role is to make sure the approach is working, re-balance the load as necessary, set priorities, and to mentor all the architects to ensure they can deliver to each of the initiatives they are working on.

Opportunistic Architecture
When money is tight in an organization, architecture has a hard time. The number of architects is generally reduced, sometimes to zero. If architecture is still recognized as adding value then as architects we need to take the small opportunities that exist.

This means getting smart over communication. A typical architecture message is about strategy, the long term, flexibility, etc. An organization that has constrained investment is usually looking at short term actions to survive – the strategy is not to spend unnecessarily, the long term will be taken care if we get there. Architects need to get “on message” or lose credibility.

We have to get smart with payback, the organization is looking for rapid payback – 3 months, 6 months, definitely less than 12 months. Therefore, long projects are out, incremental delivery is in. Do something, get some payback, do some more, get some more payback, bring the benefits forwards. Doing this you are helping your organization meet its strategic need to survive, you are showing that you business savvy, you bringing forward the day when the investment constraints get lifted.

We have to get smart with suppliers. Some suppliers will play ball and use value based pricing. This means that they paid based on the value that you receive rather than the capability of the product i.e. you buy a strategic product that gives you a foundation for the future but only pay for what you use. The supplier wins because when you expand usage they additional revenue with minimal presales effort. You win because you get an architecturally sound base to build on. But, you need to get price protection on your future usage so you don’t get screwed on licenses or maintenance.

We have to get smart with projects. You are trying to get each project to put in place a small number of building blocks for the future. You need to persuade them that this is at no extra cost and requires no extra time – they are under pressure. You need a very clear vision, it needs to be pragmatic. If it’s too complex or too big then the small steps will give you too little progress.

Guerrilla Architecture
When you get down to zero and architecture is not seen to add value then the only thing left is guerilla action. You have to be opportunistic but you can’t do it openly. You may also have to resort to sabotage where short term parochial actions are damaging the organization.

You are now playing a dangerous political game. You are exploiting failures to promote more thoughtful planning. You are chipping away at the credibility of others who may have more power than you. You fail if you don’t survive.

You are the one who says “I told you so” and then have a recovery plan. You are the lone voice in the wilderness. Sometime in the future, people will realize and understand that you were right. These people are politicians so they will take your ideas and claim them for themselves. They may even try and discredit you.

Guerilla action is not easy, you will likely lose. But hey, you had already lost, guerilla architecture is a way of retaining your integrity and maybe there is a slim chance of winning.

 

[Ref: http://chiefarchitect.squarespace.com]

Posted on

Why TOGAF is more adaptable to Enterprise Organizations?

 

The Open Group Architecture Framework (TOGAF) is the leading enterprise architecture frame work. There are so many frameworks but it may be confusing which one is the best fit for your organization. Especially, when there are more than 20 frameworks that are used to do enterprise architecture. These frameworks can be categorized either as industry specific or corporate propriety. While, we are not arguing the value of these frameworks when they are put into practice in an organization. There have been many result oriented architectures which organizations can claim success from these frameworks.

What makes TOGAF important to the enterprise architecture community is that it is a framework which is built on open standards. This translates to organizations being able to use TOGAF as their enterprise architecture framework for free. They do not have to pay any organization maintenance cost or anything to implement this framework. Companies are always looking for ways to save money especially with cuts in corporate budgets and the need to do more work with less resources. The TOGAF framework has a strong user community who supports the development of the framework. This is one of most adopted frameworks by organizations across the globe. This leads to more opportunities for organizations to find resources in a domain which has been notoriously difficult to recruit qualified enterprise architects capable of understanding how their company does business. Since the company uses TOGAF then they build their architecture the same way that other organizations build their architecture using this framework. The ability of organizations to leverage their resources to capitalize on the benefits of TOGAF would truly make a difference in organizations making better decisions on their technology to support their business needs.

The TOGAF framework has been tried, tested, validated in many organizations around the world. This framework can be used with other existing management frameworks that your company may use. For example, if your company uses ITIL then you can also integrate the TOGAF into the practices of ITIL. There are many benefits from having a framework which is widely used, accepted, and an industry standard. Your organization should pick a framework which will develop the type of artifacts that are needed which are specific to your organization’s needs. When you implement processes, procedures, governance, and structure to manage your enterprise architecture then you should see greater corporate agility, communication, collaboration, and better decision making by corporate executives.