CHAPTER 16
Executing Your Initial Projects

Your first project will be pivotal. A success will help others see the potential in the approach. What follows are some suggestions for getting the most out of this first endeavor.

Think big and start small

One consistently relevant bit of advice is to “think big and start small.” Most IT initiatives embrace one axiom or the other, but not both.

Most projects start small. Unfortunately, when “start small” is the only rule you follow, silos are quickly created. In the same way that every application in an application-centric enterprise, creates its own siloed database, “starting small” (as with traditional agile development) each small project tends to create its own data model.

While starting small is generally a good strategy, it is not enough by itself. We need something to unite the small initiatives. We call that the “Think Big” aspect of the approach.

On the other hand, “thinking big” by itself usually results in very grand plans that don’t get implemented. This is where the “Enterprise Data Model” came from. Worse than a grand plan that isn’t implemented is one that is. Some of the worst debacles in corporate hubris have been the gigantic “think big, implement big” projects. We don’t know of any that have succeeded, but we’ve heard of many failures.

The way we balance these concepts is by having the “think big” portion be limited in duration, but not in scope. We find that it is possible to get a pretty good enterprise ontology for most firms in about three months. The three-month time frame keeps it from being a massive study. Following close on the heels of the ontology is its first application (the think small part). Typically, we’re looking for something that can be implemented in a few months, so the scope needs to be pretty small. This combination gives sponsors a great deal of confidence that they aren’t investing in a science project.

The first small project may not be ready to go directly into production. The functionality will only be built toward the end of the three-month sprint, and there won’t have been enough time to procure infrastructure and the like to take it into production. In many ways, it is a demonstration or an experiment, but as we caution below, it is good to avoid labeling it a “Proof of Concept.”

By building the “small” in the context of the “big,” we avoid creating another silo. We also can test out key parts of the “big.”

Enterprise ontology

The core of the “think big” portion is creating an enterprise ontology. Most people have given up on the idea of any sort of enterprise data model, as their history has told them that these efforts are expensive and not useful.

We think the key is to get the maximum amount of coverage with the fewest number of concepts in the enterprise ontology. What we mean by coverage is as you subsequently detail out specific subdomains or applications the hope is that the specific concepts in the subdomain are specializations that were defined in terms of the concepts in the enterprise ontology. Whenever we come across a concept in a subdomain that has no logical parent in the enterprise ontology, we call that concept an “orphan.” It is inevitable that there will be a few orphans, but each one should cause you to question your enterprise ontology and your design approach. A true orphan will not be discoverable in enterprise queries and will not participate in the overall integration.

The following example is a great illustration of how this works when it works well. Our firm was working on design only in this case, so we did not ever implement the system, but it still provides a more concrete example. We worked with a State Department of Transportation, and you really can’t get more concrete than highways. We built their enterprise ontology, which contained concepts including:

Most of those are self-apparent, except perhaps the last. A “roadside feature” is anything permanently attached to the surface of the earth that you could conceivably hit with a car. It includes trees, large rock outcrops, signs, and the like. It does not include dead animals; while you can hit them, they aren’t permanently attached. Roadside features must be near enough a roadway that it is likely that they could be hit.

As we started reviewing some of the more specific systems they were managing, we discovered a “fire hydrant” system, which kept track of all the fire hydrants in the state. Almost all Fire Hydrants are near roadways; they aren’t of much use otherwise.

The fire hydrant system contained data including names of fire departments, ID numbers of individual fire hydrants, hydrant locations, water flow measurements, and the contact information of people with access to turn hydrants on or off. It turned out that all these concepts had covering concepts in the core. A covering concept is a broader concept, where the detailed concept is a specialization.

In this example, FireDepartments are specific kinds of Organizations. Their Contact info was specialization of Person and Address, and the AdjLaneMile was a specialization of geospatial information(Location) and would be located on or near a roadway. The flow volume of water is a Measurement, typically in units of cubic feet of water per second. The fire hydrant itself was a Roadside Feature.61

Therefore, if someone queried the fire hydrant data using only the enterprise ontology, they would receive all the information that was available in the fire hydrant system, without having any prior knowledge of the fire hydrant schema. They would see roadways, latitude, and longitude; they would see organizations and measurements of substances; they would see addresses. They would see a “RoadwayFeature” that was identified as a FireHydrant, despite having no have prior knowledge of FireDepartments, FireHydrants, and perhaps even Water. But the definition of each of these would be just one click away for anyone curious.

Gist as a starting point for your ontology

Establishing a solid Enterprise Ontology early will create a great deal of confidence in the whole endeavor. Semantic Arts have developed a free “upper ontology” upon which you may base your own enterprise ontology. We call this framework “Gist.”

Gist is freely available. It is licensed under the creative commons share alike license and only requires that you post an attribution in your ontology files and that you do not change the namespace. Documentation and the ontology itself can be found at www.semanticarts.com/gist.

We have been building enterprise ontologies for 19 years. Twelve years ago, we began distilling our experience into a shareable base model, naming it “Gist” for the English word meaning “the essence of.” Since then, we have used Gist as the basis for every enterprise ontology we have built, in nearly a dozen different industries. We have been refining Gist as well as our methodology for leveraging Gist over this time period such that we now have a great deal of confidence that we can derive an enterprise-specific ontology of very high quality and completeness in a short time frame. We have come up with the term “orphan class” for any new class introduced in an enterprise subdomain that isn’t a specialization of a gist class. Or to use our prior term, doesn’t have a covering concept in gist. In ten years of working with gist, it has gradually evolved to where most new concepts we encounter do have covering concepts in gist. Our desire to have the ontology be elegant and understandable has led to our continually pruning away concepts that are not essential.

Gist comprises 15 high-level concepts that cover most of the enterprise concepts we encounter in enterprise systems. These 15 high-level concepts are further specialized, making the ontology essentially directly implementable. As of gist version 8.0.0, we now have 127 classes and 119 properties, or ways to connect instances of these classes.

Each industry and each enterprise is different. As such, the concepts and terminology used by Gist must be specialized before it is applied. Regardless, we have found it rare for a finished enterprise core to be larger than twice the size of Gist. Most enterprises have sub-ontologies (we introduced this idea in Chapter 9); each sub-ontology typically adds many dozen more concepts. Even when all the ontologies and sub-ontologies are added up, an Enterprise Ontology derived from gist is still of manageable complexity.

Pilots, not POCs

Many enterprises and vendors have conspired to make doing a “proof of concept” the standard first phase of any project. NASA, perhaps more than any other agency, have made their legacy by moving things from wild idea to standard practice. They created the “Technology Readiness Level,” which has nine levels of “known-ness,” which in turn shape their approach to contracting.

The levels range from TRL 1, which is for basic scientific research, through to TRL 9, where an actual system has been proven through successful operation.

What we have noticed is vendors tend to like “Proofs of Concept” in that they are to be a first stage in their sales process. If the vendor is selling a product with a high margin, they don’t mind that they lose money on these “Proofs of Concept.” On the other side, clients have learned that vendors are often all too willing to invest in occasionally elaborate POCs without being funded.

Many mid-level managers in large organizations, without access to budget, found they can do a great deal of very interesting research under the banner of POCs. We heard tell of one mid-level manager at a Financial Services firm who bragged that he had sponsored over 100 free POCs in his career.

At one level this whole Proof of Concept thing seems pretty innocent. If vendors are willing to do them for a chance at a real project, and if clients get value from them, what is the problem?

We became sensitized to the downside of Proof of Concept projects from one of our clients. They were talking internally and had sponsored so many Proof of Concepts (POCs) that they pronounced it “pock.” They said they had gotten to the point where they would tell a vendor, “We’d like a proof of concept to see if you can make the sky purple.” The vendor would go away for a while, then come back and demonstrate their new sky purpling capability. At this point, the client said, “What are we going to do with a purple sky?”

Around this time, we began to realize that POCs were far less innocuous than we had thought. By focusing on these demonstrations of things that either didn’t need to be demonstrated, or that would have no commercial use even if they were real, lead to a lot of wasted time on both sides.

As a result, we concluded that there are very, very few projects that need proof of concepts. Most of the technology that most corporations are going to implement exists and has been successfully implemented by many firms already, so a literal POC in the spirit of a NASA TRL-1-5 is not needed.

What makes much better sense is a pilot. A pilot is a small-scale implementation of a technology that has been proven, but it isn’t known how it will be implemented at a particular site. This is very different from a POC. The problem with a POC is even if it is proven, it takes a lot of imagination to figure out how it will be applied to a real business problem. With a pilot, most of the economics have already been worked out. The pilot has a business case, whereas the POC typically does not. The easiest way to tell the difference is to ask yourself: “If this experiment succeeds, will people be eager to implement it?” If the answer is “no,” it is very likely it is a Proof of Concept without an attendant business case. If the answer is “yes,” you ask, “What do we need to do to roll this out on a broader scale?”

True contingencies

If you have found yourself embarking on a large death march project (a project likely to cost $100 million or more, and which statistically is highly likely to fail), you have an interesting opportunity. We call it the “true contingency.”

Most projects of this size have a contingency budget. In a triumph of optimism over experience, this budget is usually around 15-20% of the total. Experience strongly suggests that this is not nearly enough. These projects often run over by 50-100% or more. But politically it is impossible to go forward with that range of uncertainty because sponsors of such projects want to be convinced that all the contingencies and risks have been considered.

Given that the contingency is going to be inadequate, and that you are going to blow through it before your systems integrators start with the change orders, it is not really providing you will an actual contingency.

Here is a strategy to consider: take a portion of the contingency and spend it on something that will provide a real contingency. Build a system in parallel in a way that if the primary project gets into financial or technical trouble, the contingent system can be brought forward and put into production.

Most sponsors won’t allow you to launch a parallel effort and will question you as to why you think you could implement a system for a few percentages of what the professionals think it will cost. This will require a slight bit of subterfuge. One tack we have been suggesting lately is to say this contingent budget is being spent on a “fully functioning prototype.” The prototype idea is that you will want to try out all the user interfaces on the intended users long before you commit to design and code some of the potentially irreversible decisions. The “fully functioning” bit is to make sure this is not just a paper or pretend exercise. You will want realistic (real) data. You will want realistic (real) data volumes. You will want realistic (real) data variability. The most realistic prototype you can build will be one based on the actual data.

If you follow the precepts in this book, you should be able to get this implemented for a small fraction of the main system budget. It will be completely obvious whether it is up to the task or not. In the worst case, you may have wasted a bit of your contingency budget on an effort that may have at least taught you something about your data and your user interfaces.

In the best case, it may save you from catastrophically bad implementation.

Corporate antibodies

An organization is designed, pretty much by accident of birth, for homeostasis. Organizations are like living things in that they are made up of many complex interlocking systems that can take a great deal of perturbation, get knocked about, and return to an even keel. Most of the time, this reliance on homeostasis is a good thing. But when an organization wants to change it finds that the systems that help it withstand threat also prevent positive change.

One of these defense mechanisms we call “corporate antibodies.” You’ve seen these. These are everything from cultural norms to turf battles. A firm will often avoid taking the action it needs to because some people in positions of influence believe the change, while good for the firm, may reduce their power or influence.

It should be borne in mind that there is nothing more difficult to arrange, more doubtful of success, and more dangerous to carry through than initiating changes. The innovator makes enemies of all those who prospered under the old order, and only lukewarm support is forthcoming from those who would prosper under the new. Their support is lukewarm... partly because men are generally incredulous, never really trusting new things unless they have tested them by experience.

Niccolo Machiavelli

Often some manager may suspect that the 100-person project they are initiating may be of marginal to negative value, but they can’t resist the allure and excitement of a project of this size.

We have a client who is keenly aware of the politics of organizations. He sponsored an initiative out of his own budget that was a more general benefit to the whole firm. As we were putting the corporate wiki page together, he asked to not have his name as the author or sponsor saying, “Once people start perceiving this as Nic’s system they will start resisting it.” His advice was that in a large organization, it is often easier to leave a legacy than get credit.

We’ve seen more good initiatives stall or fail for political reasons than all other reasons combined. Be constantly vigilant.

Federated development

We are just beginning to see a new pattern of application development emerging. Rather than copying data from a system of record into the system being implemented (which is the current standard), Federated Development says: let each data owner, each steward, own their data and allow others to access it, as needed.

This is done now in a limited fashion with Master Data Management (MDM) and some API-based development, but these approaches rely on a great deal of programming and coordination.

With data in a standard format (triples), it is possible to construct queries that can combine data from many repositories in one query. This is very difficult to do with traditional technology. It is now possible to federate queries that combine graph data with maps that make existing relational data look like triples and conform to the ontology but only at query time.

Adopting a federated development approach puts you on the road to the end of reconciliations and the end of data conversions.

An enterprise knowledge graph

Google has popularized the notion of a Knowledge Graph. In Google’s case, their graph contains the sum total of everything they have learned by scrapping and re-scrapping the web, as well as from mining your queries, your reaction to your query results, and the effectiveness of all the ads they have placed.

For a firm, the Knowledge Graph is the sum total of what the firm knows, organized around a central model. It comprises the structured data, as well as the myriad bits of miscellaneous “knowledge” captured and organized elsewhere (e.g., in external spreadsheets). With a Knowledge Graph in place, a firm will not only enjoy access to all they know – they will be able to infer more from the information already there.

Chapter Summary

Your first few projects will be key to getting a Data-Centric culture established. There is a certain amount of tension between solving the broad firm-wide problems and tackling specific, quick-win projects.

Our advice is to embrace the tension. Start with a first version of an enterprise ontology. Even if it is very thin, it will guide future integration and hold the whole initiative together. At the same time, build out something specific of value. This initial system will often be the integration of several other systems that have been historically hard to integrate. It may be the integration of two types of data, such as structured and unstructured. This is often enough for others to see the value in the approach.

The elegance of your enterprise ontology will be key in keeping the tide of complexity at bay. Your first projects should be examples, existence proof that this new approach is viable and desirable.

We have seen the firms that get off to a good start get results in a short enough time span that they are encouraged to stay the course. Early wins lead to additional investment and each round of success brings you closer to the ultimate goal.