Why Consultants DON'T use OOAD!

"We don't create Domain Models"

Just before I quit my last job to start a company, I was frequently visiting a friend of mine who was (and still is) one of the most sought software-development consultants at the time. I was nervous about starting my own company and would constantly ask his advice on various aspects of the software business.

There was one piece of advice that really surprised me. "We don't create Domain Models." I was speechless. The Domain Model, after all, is at the heart of Object-Oriented Analysis and Design (OOAD). It is a software model of the business domain. It embodies the various business entities (Customer, Employee, Purchase Order, Invoice, Product, etc.) and the business rules that govern their interactions. It makes the maintenance of a enterprise software system economical because new applications would simply be built on top of the domain model, and the business rules will be reused. Implementing changes in the business rules would also be economical because changes to the Domain Model would propagate to all the applications built on top of it.

Why, then, did my consultant friend advocate otherwise? "“It takes too much time", he said. "“It's so much faster to implement each function as a large vertical slice."” The unspoken penalty, of course, is with the client, who has to bear the cost of maintaining the system.

Game Theory

And so plays the game theory of software development consulting. Even if some consultants know that establishing a Domain Model for their client would be in their client's best interest, they don't do so because they lose out when bidding against other consultants, who promise to deliver faster and cheaper, but don't speak of maintainability.

To elaborate, here's how the game goes. Enterprise Client says he needs, say, a resource-management system implemented. Enterprise Client entertains bidders for this project. Big-Picture Consultant proposes a design that is based on a Domain Model, so that Enterprise Client can easily add other applications and features to the system or easily modify business rules. However, Narrow-Minded Consultant proposes a design that has screens making direct calls to a database. Guess what? Narrow-Minded Consultant's bid is half the cost and takes half the time. Of course, Big-Picture Consultant's proposal has a net value that is many times more than Narrow-Minded Consultant's proposal, but this argument somehow fails to make its case in Enterprise Client's corporate budget meetings. So Narrow-Minded Consultant wins the bid.

Narrow-Minded Consultant has an extra benefit. Since it becomes difficult to extend or modify Narrow-Minded Consultant's application by anyone else, Narrow-Minded Consultant gets hired again for any new work that needs to be done. Bad software engineering leads to job security!

The saddest part of the story is what happens to Big-Picture Consultant. In order to win future bids, Big-Picture Consultant decides to no longer propose the implementation of a Domain Model, so they can bid at prices and schedules comparative to Narrow-Minded Consultant. (I think my friend falls into this,– a consultant who wants the best for his clients, but is required by competition to compromise on this.)

The Story for Enterprise Clients

And what happens to Enterprise Client and other companies like it? It ends up with "“island applications" that do not integrate well with each other, and it ends up being dependent on the consulting companies that built them.

If Enterprise Client is big enough, some big-name vendor will start selling them on some "SOA" solution, but still won't address the fact that Enterprise Client needs a unified domain model behind whatever integration solution that is proposed.

Moral of the Story

So what's the moral of this story? It's up to the Enterprise Client to require consultants to commit to proper Object-Oriented Analysis and Design, including the proper implementation of the enterprise's Domain Model. It's only the Enterprise Client who stands to benefit from a well-designed Domain Model, not the competing vendors.

If Enterprise Clients fail to understand the value of OOAD and impose it on their consultants, consultants will be driven to forgo careful OOAD in favor of the very narrow implementation of project requirements, in order to bid lower and faster than each other.

It is important for Enterprise Clients to own their systems' design. Notice I did not use the overused buzzword "architecture", because I did not want you to think that all one needs to know is a very high-level "architectural" appreciation of the Enterprise's systems. What I mean is that the IT department has to go far, far beyond just managing applications and outsourced services. It has to really know the business of the company to which they belong. It has to invest in the careful discovery and analysis of the various entities, business rules and workflows of the Enterprise, and continually invest in keeping this knowledge updated, because these facts will continuously be in rapid flux.

Ask yourself: On the wall of your company's CIO, does he have a class diagram depicting the Domain Model of your company? Off the top of his head, can he recite the most important entities of the company for a particular aspect of the business, and discuss the workflows and business rules associated with them? If not, then before you make your next software investment, you need to invest in making sure the CIO and the other top IT execs know your business.

Picking the Right Consultant

Ok, I'll admit, this is the part where I make a shameless sales pitch, but here it goes. A lot of people know that Orange & Bronze is full of Object-Oriented zealots. The reason we chant the mantra of OO is because we also chant the mantra of providing the highest value for our clients (whether they know it or not). It saddens us to see IT managers struggle under the weight of managing disparate yet rapidly growing systems.

In every project we bid for, we attempt to provide an allowance to include careful modeling of the business as a Domain Model within the software. This has sometimes meant that we have lost because we are not able to bid as low as some of our competitors, oh well. But in the clients who we are able to serve, we leave a highly extensible and maintainable system on top of which they can economically build other systems or economically accommodate changes to business rules.

Orange & Bronze can work with your company to provide a careful discovery and analysis of your business's entities, business rules and workflows. We can then implement such knowledge in the form of software as a Domain Model, which can be reused over and over again for both present and future software applications of your company.

Recommended Readings

Domain Modeling - Paul Oldfield
Patterns of Enterprise Application Architecture - Martin Fowler
Domain-Driven Design - Eric Evans