Yes, these are the tenets that must be established to withstand the passage of time and to survive the challenging trials a complex project presents. Category I Tenets are not meant to vary over time, all the more reason for them to typically prescribe common-sense best practices. In many ways these tenets are so common-sense that their ‘motherhood and apple pie’ texture make them appear as though they are just a collection of distilled clichés. I suspect that when you read through the sample of Category I Tenets below, you’re going to say, “Duh! These are so obvious, why even bother to mention them?”
Well, we live in a world where many believe we didn’t really land on the Moon; where the so-called “birthers” refuse to acknowledge President Obama’s birth certificate, and where many think 9/11 was a self-inflicted government conspiracy. Irrationality loves the vacuum. Even if you discount all irrational arguments, the fact is there are a surprising number of cases where rational counter-points can be made to what seems to be a solid, “clearly-uncontestable” tenet. Even “obvious” tenets should be stated explicitly or you could risk someone, somewhere along the line, taking the counterview based on the validity of an isolated exception to the rule, or on the strength of an individual’s forceful opinion.
Take for instance the tenet, “Be Proactive; not Reactive”. This statement seems so obvious as to be unnecessary, but there are those who might argue that being reactive is a lower risk proposition, especially if agility to quickly catch-up with the competition’s first moves can be maintained. To them, the tenet should read, “Be reactive, but be quick to adapt to changing conditions”. In this light, the former tenet doesn’t sound so obvious anymore. Who knows, based on differing conditions it could well turn out that you transformation strategy should after all be reactive.
It’s important to state the Category I tenets openly and unabashedly. Following are a few sample Type I Tenets, representative of the kind of Category I Tenets you’ll need to define. Even though I am quite certain these tenets will hold water under a large number of conditions, they were selected under specific situations that might differ from yours. Clearly my list is not exhaustive, and yes, my lawyer also advices to remind you that you should be able assess these tenets in the light of your own transformation effort and use alternate or even opposite tenets as appropriate!
· Functionality requirements must be driven by the business requirements.
This statement simply reinforces the need to ensure that business is involved from the start in defining the specific features and priorities. However, getting the attention of business for what is essentially a strategic initiative can be a difficult undertaking. Business folks are typically immersed in addressing short-term issues. More significantly, typical business executives rarely focus on strategic technology issues (actually, that’s a good thing as this should be your responsibility; not theirs), so you will have to go the extra mile to extract and map the business requirements needed to create the technology plan.
· Be Architecture Driven; Not Vendor Driven.
This is a Zen-like “Be-the-Architecture”. Remember, we are talking about the transformation of IT elements that provide key competitive differentiators to your business. ERP is sufficiently commoditized so that most companies should be happy to follow the lead of vendors in this area. And yes, if you buy into the SAP or PeopleSoft views of the world for these particular IT domains, you will be just fine. Remember, however, that if you are to buy into the complete architecture view of a vendor for the development of your new core technology, you are making a generational commitment to that vendor—a commitment that ties your company to the vendor’s future for eons to come. I can’t tell you how many times I have come across companies that fully bought into a particular vendor’s architecture only to see that vendor go the way of the Dodo (an extinct bird—check it out in Wikipedia). What this tenet says is: design your architecture according to your company’s needs; make the architecture vendor-neutral, and then and only then approach vendors to ask them how they can help fulfill your vision.
· Use of off-the-shelf industry standards and products is preferred for all commodity-level elements
I’ve seen my share of companies who’ve spent an inordinate amount of time and effort developing their “own version of network protocols”, or their own “very cool, in-house version control system.” Unless there’s a clear cut reason for you develop a commodity component in-house, you’re better off having your team develop only those components that will create differentiating solutions. It’s wiser to focus on providing value-added features not readily available on the open market; the kind of features that leverage your company’s core competencies rather than divert resources to areas that can be easily met by a simple product purchase.
Now, this tenet might be seen as possibly contradicting the prior one (Become Architecture Driven; Not Vendor Driven); so let’s clarify: defining a “proprietary” architecture is in no ways wrong, but in fact is advisable. A bespoke architecture, however, does not presume the use of proprietary components. In fact, an architecture that’s well tailored to your needs will wisely identify the areas of focus for differentiated, value added development, and the areas and manners for interfacing off-the-shelf components.
· Architect from a Holistic Perspective
Don’t focus just on the needs of a particular business function or department. If the sales department requests a Prospect Tracking Tool, you could spend you energy defining the contact management tool requirements, designing the workflows and data bases involved, and defining a terrific prospect tracking tool. However, if you fail to think holistically by envisioning the synergies that can make the tool better you will be de-meriting the solution. What if you could tie in this solution to a more generic customer data base? What if you could gather customer purchase history and tie that information in with the tracking tool? Say, you were to find out that for the past two years you spent X amount of hours wooing a customer who generated only a minimal amount of business, while another customer, who had been contacted only a few times now represents 10% of your revenue? Wouldn’t you like to design a system capable of managing such a broad view?
Before you accuse me of over-scoping with a “what if all that’s needed is a tracking tool; nothing fancy or expensive!” I am not suggesting that you actually implement this type of holistic design. I’m suggesting that you architect the solution so that, should you decide to implement it, it will take into account the potential interactions with the rest of your system.
· Move to Service Oriented Architecture.
Enable an end-to-end, distributed service oriented framework that provides all necessary services independently of the underlying technical infrastructure. Arguably this is a Category II tenet, but given SOA’s establishment as the de-facto architecture pattern for modern systems, I think this is now a tenet that has attained a chisel-in-stone status.
· Minimize costs by driving reuse and convergence
This is like understanding the need for exercise, not smoking, and avoiding fats—obvious advice that’s rarely followed. Many choose time-to-market even with the added costs this heterogeneous solution demands. “You want a new campaign management solution? No problem! Let’s buy that super-expensive module from that company that invited us to the Ryder Cup last year! Later on, we’ll figure out some way to tie their customer data base in with ours!”
· Place automation of core business functionality in back-end systems
It is better to have the bulk of the capabilities served via back-end engines rather than designing a monolithic front-end that implements all functions. Many Web sites that have attained a large size organically are now suffering from limited scalability due to the failure of their designers to move the business logic to backend engines. The front end component should be limited to providing user interface capabilities such as interaction workflows and presentation level integration, and access the backend business processes via services.
· Keep the number of programming languages (and redundant technologies) to a minimum.
I am old enough to remember FORTRAN, a language widely used for scientific work. Then COBOL was invented by the great Grace Hopper to be the language of choice for “business applications”. Next came PL/I, an IBM specification that kind-of-combined COBOL with FORTRAN. As if PL/I were not bloated enough for the US Federal Government; the Department of Defense invented ADA, which is probably gathering dust in some of those old computers running the country’s nuclear silos (so it’s a good thing that ADA was a strongly typed language!). Meanwhile, a host of other languages sprouted-up like weeds in an unkempt backyard. We had Basic, LISP, Algol, Modula, Eiffel, and C, then C++, followed by Java which is “like C++ but with garbage collection and no pointers”; then came the wave of scripting languages that have come to look more and more like actual languages. Enter the Ruby vs Python debates.
I am certain that ten years from now, a similar passionate debate will be raging between followers of two as yet unknown languages (I don’t envision the day when computers will be programmed in plain English. Call me a nerd, but why we would we want to tell the computer to “Move money in the customer savings account to his checking account” when a simple Customer.TransferMoney(From, To, Amount) would do?)
Bottom line is that there are now literally thousands of computer languages (compiled and interpreted) out there.
You just don’t have to use them all!
The trouble with languages is that they tend to become the object of emotional preferences. It is natural that programmers familiar with a given language will gravitate toward that language. In large projects especially expect to be pressured to allow whatever programming languages your programmers’ desire. If there is an area where the proverbial stake needs to be sharpened, polished, and put into the ground, it is on this one! It is important that early on in the project you establish the tenet of using no more than two programming languages, and no more than one scripting language.
This tenet should also extend to the use of any other redundant technology: keep the number of J2EE Platforms to a minimum; keep the number of RDBMs to a minimum . . . You get the idea.
Now, I am not saying: “Have only one RDBMs solution”, or “Have only one Language”. Strive for simplicity, but not so much so that you become simplistic!