9 ITIL Implementation Challenges

ITIL implementation is no cakewalk. ITIL impacts your entire organization — your business, your IT department and your in-flight projects. The most common implementation challenges include:

1. Management Commitment

The biggest problem ITIL implementations face is when executive management approve the ITIL program but then fail to follow through with strong sponsorship support.

2. Resistance to ITIL

ITIL represents a broad organizational change that is always resisted. Departments, teams and individuals tend to defend the status quo.

3. Project Culture

ITIL isn’t a project with a completion date. It’s a set of processes that must be continually improved. There are plenty of organizations who “do” ITIL and then move on to something else. This approach always fails.

4. ITIL for the sake of ITIL

Organizations that seek a rubber stamp from ITIL (e.g. ISO 20000 certification). Such organizations see little business value in ITIL and seek to minimize implementation costs at the expense of true ITIL success.

5. Business Acceptance

ITIL isn’t transparent to the business. For example, it may change the way that business submits change requests or opens support tickets.

It’s important that business be a strong supporter of ITIL from the start (program initiation). Otherwise, ITIL may be viewed as bureaucratic nonsense. ITIL implementations are rarely successful without business buy-in.

6. Big Bang

ITIL has numerous processes. Each ITIL process has a large organizational footprint. Full implementation of ITIL is best done in phases. A big bang ITIL implementation has the potential to disrupt IT and business operations.

7. Naive Implementation

Throwing ITIL over the wall and hoping it takes hold.

8. Tools

ITIL isn’t a technology. However, it’s nearly impossible to implement ITIL processes without technology. Technology implementation is often amongst the greatest ITIL challenges.

9. The Moving Target

Many organizations that were in the middle of ITIL V2 implementation were thrown off track by the considerable changes in ITIL V3.

Challenges:::: Enterprise Architecture

Compared to many industry practices, EA is considerably an emerging discipline which still take time to mature, in last two decades, there are many challenges literally EA programs face, organizations need to analyze them and understand the underlying causes

  1. Fitness for purpose. Consistent definition and understanding of EA as a discipline adds to challenges. Most organizations stand up EA to “fix” an organization without giving it any purpose. Often, consultants/contractors try to sell the Titanic of EA before they can prove a sailboat which can float. This is what often results in annoying the clients and has lead to the view of EA being shelf-ware.
  2. Senior executives buy-in and continuous focus and support upon the EA program. This is like a chicken and egg issue. Executives would have continuous support if EA can deliver value,  but EA need continuous executive supports to show value. EA is in a domain where you don’t find too many quick wins. In addition, a successful EA would often lead to corporate culture change. Without strong senior executives’ commitments, corporate culture change just won’t happen. Many feel that time and money is being wasted till they start seeing in the results.
  3. Understand Stewardship and Ownership differences. Too often an EA attempts to take ownership of a business process and ends up getting blamed. An EA is a Steward to practice strategic EA Leadership & Operational Stewardship –> alignment of execution with Strategy is extremely critical for EA success.
  4. EA Maturity: EA engagement model and governance. This gears toward corporate processes, politics and people issues. Enterprise Architecture is simply a heavy burden to a lot of people and projects if EA engagement and governance model is not efficient and effective. Somehow, fragmented EA engagement model and governance process is very common at work place. It seems taking forever to streamline. In other words, Governance and Compliance inward is extremely important.
  5. Organizational Maturity. A mature organization is base to start a successful EA program; on the other side, an effective EA program improves organizational maturity. Too many organizations try to institute an EA program when the organization is not prepared to do so. Often, leadership hears or gets the pitch that EA will save the day and they start a program, without supporting the program, thinking that “doing” EA will fix everything. EA requires wide preparation and active participation.
  6. Business/Architecture Alignment –> This has to be earned by EA Team and should not be considered a blank check or an entitlement, as this would require relationship management and transparency in delivery to match the business priorities. PMO and Architecture team are critical for earning and establishing the trust.
  7. Move from Vendor/Group/Institute-centric EA to Customer-centric EA. Advance from just being DNAor “enterprise genotype” (a full nomenclature of enterprise artifacts) to provide a formal link with “enterprise phenotype” (a set of observable characteristics such as performance) and business ecosystem.
  8. Constant jockeying with “tactical project savings” vs. “sustainable strategic advantage” argument…(classic misalignment of project team goals with architecture team goals!).  Starting too big,  that the EA initiative doesn’t get success as originally intended. It is extremely important to start small and produce results to gain trust. Planning and prioritizing some quick wins to demonstrate what change a complete EA can bring to a enterprise. Though it is very difficult since it can backfire at times. Still, EA needs to demonstrate directly quantifiable ($$$) value – contribution to company’s bottom line or direct savings as a result
  9. Mature EA Team: The EA team which don’t just believe in Framework and Technology but also has the capability to carry the business with them and got a thick skin to sail through the politics and policies Staff. Also, it is not about the “chief architect,” it is about the team of architects/support staff, a mature EA team. 
  10. EA Skills/Talent: Architecture is more of an art than a science and requires more skills than certifications. Enterprise Architect requires broad knowledge from many aspects of, business domains knowledge, technologies project management experience, and organizational skills. There are many channels to mature as an Enterprise Architect. Enterprise Architects with different maturing paths may see the same organization with very different challenges.

Why Enterprise Architecture fails??????

1. Lack Of Sponsorship.

Your architects need three tools to do a good job: access, leverage and goodies.

Access means the ability to interact with the appropriate stakeholders, often at the C-level.

Leverage includes the right place in the reporting chain, involvement in governance, ability to influence the technology budget, and authority to stop inappropriate technology implementations. Sometimes even the seemingly small change of a title from technical architect to chief enterprise architect can make a significant difference.

Goodies include the ability to give out new technologies for testing, “lend” technology experts to struggling projects, and get access to exclusive information that can be traded for favors.

Well-sponsored architects will be able to build trust by consistently delivering meaningful results. Lack of sponsorship will destine even the best architects to fail.

2. Hiring Or Promoting The Wrong Person.

The skills that earn someone the EA position don’t necessarily make the person a strong EA. Often the most technical people get promoted when they lack other important skills. These include interest in the business, the ability to translate technology into simple business outcomes, and the ability to listen, communicate, present and market infectious enthusiasm for new technologies.

3. Building An Ivory Tower.

Some EA programs hire a bunch of brilliant architects who retreat for a long time and return with sophisticated frameworks. They then present them to key members of the leadership and the organization, most of whom will have no clue what the architects are talking about, so their complex reference architectures will be ignored.

Ivory towers tend to increase the complexity and upset the stakeholders. The new CIO will gain immediate recognition among his business partners by firing the EA team, with the result that enterprise architecture becomes a “bad word” deeply embedded in the institutional memory. Roger Sessions wrote a great white paper on driving simplicity through connected enterprise architecture.

4. Policing And Insensitivity To Culture.

I have seen a project manager burst into tears in the crossfire of enterprise architects’ questions during a technical design review. I have been on a 2 a.m. call struggling to comply with unreasonable and obsolete technology standards just to get the chief architect’s signature and meet the budget deadline.

In that particular case, the turning of enterprise architecture into a policing function resulted in its failure. It takes a lot of effort to convince, and regularly re-convince, your business and IT partners of the value of enterprise architecture. A gentle approach makes the function more likely to succeed. The best architects I’ve known spoke softly and carried a really big carrot. They followed Exupery’s advice.

5. Maintaining The EA Artifact Factory.

Some EA teams keep busy documenting as-is states. They have an incredible array of diagrams at their disposal to represent the various aspects of everything. The world of diagrams is addictive, and perfect is the enemy of good when it comes to diagrams.

Instead, these teams should focus on producing frequent, meaningful and measureable business outcomes.

It isn’t easy to come up with good KPIs to measure enterprise architecture. This GAO report clearly shows the challenges of defining good EA metrics in the government sector.

6. Clinging To A Particular Framework Or Tool.

There are more than 80 EA frameworks, and you’ll find no silver bullets among them. The best approach is to read all of the major frameworks, discard most of what you have learned, and blend the remaining 10% in a way that fits your organization’s culture, maturity and business goals. As an example, here’s a lightweight, blended approach for tree huggers. When it comes to tools, go fancy if you have the money. But most of the time fancy isn’t necessary. Visio, Excel, Word, FreeMind, Prezi and a collaboration team site works well. Limit the time spent on selecting tools and frameworks and instead focus on using them.

7. Thinking Enterprise Architecture Equals Technology Architecture.

Most EA programs are initiated by IT and never progress beyond the technology domain. Although technology standards, technology roadmaps and solid engineering practices will produce simpler, cheaper, portable, reusable and more supportable solutions, they don’t align your IT investments with business goals and won’t power your business with technology innovation.

8. Taking The “Enterprise” Word Literally.

“Enterprise” does notnecessarily mean the entire enterprise. It means stepping back and taking a look at the higher-level context before making a decision. Moving architecture to the real enterprise level requires a mature and committed organization. If you try to push the enterprise aspect too far too early, you’ll crash and burn.

TOGAF® 9 Template Artifacts and Deliverables

This is an example set of templates for TOGAF 9. It includes example artifacts for all catalogs, matrices, and diagrams, and template deliverables.

Example artifacts are as follows:

  • Catalogs:
    • Application Architecture: Applications Portfolio Catalog, Interface Catalog
    • Business Architecture: Contract-Measure Catalog, Driver-Goal-Objective Catalog, Location Catalog, Organization-Actor Catalog, Process-Event-Control-Product Catalog, Role Catalog, Service-Function Catalog
    • Data Architecture: Data Entity-Data Component Catalog
    • Preliminary: Principles Catalog
    • Requirements: Requirements Catalog
    • Technology Architecture: Technology Portfolio Catalog, Technology Standards Catalog
  • Core Diagrams:
    • Application Architecture: Application & User Location Diagram, Application Communication Diagram, System Use-Case Diagram
    • Architecture Vision: Solution Concept Diagram, Value Chain Diagram
    • Business Architecture: Business Footprint Diagram, Business Services and Information Diagram, Functional Decomposition Diagram, Product Lifecycle Diagram
    • Data Architecture: Class Diagram, Data Dissemination Diagram
    • Opportunities and Solutions: Benefits Diagram, Project Context Diagram
    • Technology Architecture: Environments & Location Diagram, Platform Decomposition Diagram
  • Extension Diagrams:
    • Technology Architecture: Network Computing-Hardware Diagram, Processing Diagram
  • Matrices:
    • Application Architecture: Application Interaction Matrix, Role-System Matrix, System-Function Matrix, System-Organization Matrix
    • Architecture Vision: Stakeholder Map Matrix
    • Business Architecture: Actor Role Matrix, Business Interaction Matrix
    • Data Architecture: Data Entity-Business Function Matrix, System-Data Matrix
    • Technology Architecture: System-Technology Matrix

Example deliverables are as follows:

  • Preliminary Phase: Architecture Principles, Architecture Repository, Business Principles-Goals-Drivers, Organizational Model for Enterprise Architecture, Request for Architecture Work, Tailored Architecture Framework
  • Phase A: Architecture Vision, Capability Assessment, Communications Plan, Statement of Architecture Work
  • Phase B, C, D: Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap
  • Phase E: Implementation and Migration Plan, Transition Architecture
  • Phase F: Architecture Building Blocks, Architecture Contract with Business Users, Architecture Contract with Development Partners, Implementation Governance Model
  • Phase G: Compliance Assessment, Solution Building Blocks
  • Phase H: Architecture Change Request, Requirements Impact Assessment

Fundamental of Data Architecture while using TOGAF

Class Diagram

The key purpose of the class diagram is to depict the relationships among the critical data entities (or classes) within the enterprise. This diagram is developed to clearly present these relationships and to help understand the lower-level data models for the enterprise. This diagram is at a high level of representation (conceptual). We are interested here in modeling the main business entities, their properties and relationships.

The TOGAF class diagram as defined is situated at an early, conceptual stage. The highest level allows the essential business notions of enterprise to be represented, without being distracted by organizational or historical complexities specific to each organization. This conceptual level enables you to think about the business, in order to define an ideal organization with regard to this particular business. These entities will be used to define business processes (products handled by processes), and will be derived to define service application components, exchange data between services and repository data schemas.

Data Dissemination Diagram

The purpose of the data dissemination diagram is to show the relationship between data entities, business services, and application components. The diagram shows how the logical entities are to be physically realized by application components. This allows effective sizing to be carried out and the IT footprint to be refined. Moreover, by assigning business value to data, an indication of the business criticality of application components can be gained. Additionally, the diagram may show data replication and system ownership of the master reference for data. In this instance, it can show two copies and the master-copy relationship between them. This diagram can include services; that is, services encapsulate data and they reside in an application, or services that reside in an application and access data encapsulated within the application.

Entity application component: An entity component is frequently derived from business entities, and is responsible for managing the access to the entity, and its integrity.

Interaction application component: Represents the top level components that manage the interaction with elements outside the IS. In most cases, it is a GUI component, such as here a web interface.

Process application component: A process application component is responsible for a business process execution. It orchestrates the tasks of the process.

Utility component: Represents an application component that is frequently reused, and most of the cases bought off the shelf.

Database application component: Represents a repository. In pure SOA architecture, these elements should not appear. However, for legacy analysis or technology architecture, modeling repositories or repository deployment can be useful.

System federation: A system federation is the coarser-grained application component. It assembles systems to federate them, such as in the example of cooperation between different information systems between different companies.

Application: This application component corresponds to legacy applications, off the shelf products, or can be an assembly of application components.

Business Entity: Describes the semantics of the entities in the business, independently of any IS consideration (e.g. storage, technology, etc).

Data flow: Expresses that data (for example business entity) is input or output from a dynamic entity.

Data Lifecyle Diagrams

The data lifecycle diagram is an essential part of managing business data throughout its lifecycle, from conception through disposal, within the constraints of the business process. The data is considered as an entity in its own right, detached from business processes and activities. Each change in state is represented in the diagram, which may include the event or rules that trigger that change in state. The separation of data from process allows common data requirements to be identified, thereby enabling more effective resource sharing to be achieved.

Identify the possible states of the entity (for example, a document can be “under-Creation”, “under-Revision”, “approved”, and so on), and then define the possible transitions between each states. A state must be a stable data situation: when no action is executed on it, the data is always in one of the identified states.

Defining the lifecycle of business entities enables better formalization of these business entities, as well as the determination of the steps that are essential to their management. This very simple state model will be a guide in the definition of business processes, since these processes will themselves have to respect the constraints defined for transitions between states: if a business entity has not passed through all its states within the business processes that handle it, then these are incomplete. If the business processes transgress the lifecyle of the business entities, then they are incorrect.


Data migration Diagram

The purpose of the data migration diagram is to show the flow of data from the source to the target applications. The diagram will provide a visual representation of the spread of sources/targets and serve as a tool for data auditing and establishing traceability. This diagram can be elaborated or enhanced as detailed as necessary. For example, the diagram can contain just an overall layout of migration landscape or could go into individual application metadata element level of detail.

Data migration can be expressed at conceptual, logical or physical level. Application communication diagrams can also be used to express the data migration. The “migrate” dependency is the key element to formalize migration.

Data security diagrams

Data is considered as an asset to the enterprise and data security simply means ensuring that enterprise data is not compromised and that access to it is suitably controlled. The purpose of the data security diagram is to depict which actor (person, organization, or system) can access which enterprise data. This relationship can be shown in matrix form between two objects or can be shown as a mapping. The diagram can also be used to demonstrate compliance with data privacy laws and other applicable regulations (HIPAA, SOX, etc). This diagram should also consider any trust implications where an enterprise’s partners or other parties may have access to the company’s systems, such as an outsourced situation where information may be managed by other people and may even be hosted in a different country.

Large diagrams can become hard to read. It is recommended that you create one data security diagram per business entity, and/or per participant (typically a role). In particular, diagrams focused on actors and their missions can provide habilitation links. Diagrams may also be focused on the external access to the system, that is on which data the external actors can access.

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.

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.

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

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.

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.

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.

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.

Benefits of Enterprise Architecture


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.


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.

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]

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.

Why Semantic web is important to business?

The “semantic Web” is hugely important to tomorrow’s business.

But what is it? And what does it mean for your business?
“Semantic” is the latest buzzword to hit the online world. It’s come to mean everything and nothing.

From semantic search to the semantic Web; and from semantic marketing to semantic technologies, it seems like everyone wants to ride the semantic train.

So What?

It marks the transition into a new phase of the Web, where we stop searching and start finding.

In other words, we discover not just the information that matches the keywords we search for, but the information that we really wanted to find. Information directly related in context, not just in keywords.

This is exactly what is happening with Google GOOG -0.46%’s semantic search, which finds content in direct response to the intent of our search query. It uses contextual signals to understand what we really mean when we type into Google’s search box, or talk to a virtual assistant, such as Siri.

New Products; New Services
The semantic Web is far more open, transparent and personalized. It’s being transformed into a place where the same content means different things to different people.

A search for “pizza” from my desktop at 9am will generate informational links and pizza recipes, yet the same search carried out on my smartphone at 8pm will pop up ads for pizza restaurants near my location.

Google looks not just at the content in its search index, but also at who is asking the question, where, and when. In a sense, it matches detailed knowledge of the searcher’s profile with an understanding of the search, in order to deliver the best possible answer.

Tomorrow’s businesses need to take advantage of semantic search.
The Age Of Checkbox Marketing Is Over
The semantic Web requires an entirely different type of thinking about online marketing content. Information placed online needs to be capable of generating some kind of interaction with the online population, which means “marketing deliverables” have to contain real value, not just keywords.

In the semantic Web, there’s no such thing as inert data: Information always means something. It becomes a signal that acquires relevance—in the right context. (I’ll explain how and why, in the next two sections.)

Similarly, products and services can no longer take the convenient approach of “one size fits all.” An online population that’s becoming accustomed to total personalization won’t take kindly to a company that treats customers as faceless numbers in a crowd.

Semantic Search Is All About Big Data
As the Web grows in size and the amount of data on it increases, the only way to make use of it is to contextualize it.

That means it can be used in a more personalized, relevant way. The moment you have masses of anything, you can find patterns emerging, which often release new insights.

The entire Big Data movement is based on this. Semantic search is no exception to the rule. The only difference is that, instead of a business analyzing data from operations, we have Google search being transformed into the world’s biggest database, categorizing the Web itself.

So how’s it achieved? How does the Web acquire greater meaning than just what’s contained in the information on it?
The Answer Lies In Hyperconnectivity
For example, if we could somehow acquire all of the world’s knowledge, it wouldn’t make us smarter. It would just make us more knowledgeable. That’s exactly how search worked before semantics came along.

In order for us to become smarter, we somehow need to understand the meaning of information. To do that we need to be able to forge connections in all this data, to see how each piece of knowledge relates to every other.

In the semantic Web, we users provide the connections, through our social media activity. The patterns that emerge, the sentiment in the interactions—comments, shares, tweets, Likes, etc.—allow a very precise, detailed picture to emerge.

That’s why the success of Google Plus is critical to Google’s move to semantic search.

The Bottom Line
The semantic Web is accelerating change across the board, challenging companies that move too slowly to adapt. Embrace it, or risk extinction.

The old rules no longer apply. If you want to be found, social is no longer an option.