EA Articles / Reference

Mendeleev "discovered" the periodic table, the set of elements in nature that all matter is made from. Gandalf is... well, the old guy that waves his staff and makes things happen outside of natural laws.

The former’s discoveries have led to the explosive advances in industrial manufacturing that we take for granted today. The latter’s (or rather, the author’s) have given us those brief moments of escape from reality that help preserve our sanity

Going with Mendeleev or Gandalf?

Mendeleev did not get rich on his discovery but millions of people subsequently did. As for the other old guy... you know the story.

Contrary to my wife’s belief that this is an excuse for my humble financial status, I make this analogy to illustrate the underlying reason why our industry and profession is in such a disorganised state, when compared to the established scientific and engineering disciplines.

And perhaps a reflection of the state of our society in general.

Is IT science, art, or fiction?

The crude distinction made between computer science and software engineering degrees used to be that computer science is more about hardware while software engineering is more about, well, software.

Then along came the term Information Technology (yours truly claims notoriety for running the first seminar in the country to introduce the subject/term) and since then it has been a free for all.

There is now a bewildering range of names, each with its own definitions, qualifications, standards and methods. Each vehemently evangelized as the one and only “true” and “best” way.

How can there be a multitude of “best,” when common sense says that best implies one? Can we accept many correct ways? And if we do, is it a cop-out? If not, what is the one ring to bind them all, or to form the baseline for them all to be compared?

Comparison not in terms of “best,” but, perhaps, in terms of “better for a given situation, time and space.”

That the hardware side of IT depends very much on science is well accepted. On the software side, the jury is still out on whether it is science or art, or magic. It is too difficult to explain the thought processes that go into making software.

Attempts to create a collection of reusable parts that can be easily assembled into new and different systems have failed. Unlike engineering blueprints, an architect/technician from one organization cannot be sure what he is looking at, when he sees another’s specification.

This has not been helped by the definitions and methods that all claim to be “architecture” — the current word that lends a ring of authority to the speaker. (A partial lineage of “ultimate solution” words would be wooden stake, silver bullet, Cobol, SAD, OO, SOA, and KPI.)

It can hurt

Now is a good time to explain the issue of science and “not science.” Science is to do with observations of nature, or natural laws that are inviolate, whether one may choose to believe them or not.

Newton “discovered” gravity when the apple fell on his head (though the apple story is more illustrative for school children than factual). He did not “make” gravity to cause the apple to fall. But since then, there have been countless products created from the fundamental laws of motion he documented.

The really interesting thing is that you cannot “implement” gravity, or any of the laws of motion. But you can have all kinds of methods to make things, or to move things, efficiently, based on your understanding of these laws.

You can, of course, use pure trial and error. Like bashing away at the keyboard to keep modifying a piece of software code, without fully understanding the reasons for the changes, until you get the results you want (or give up from exhaustion).

That is not very smart. And it is not that uncommon simply because many or us think that it is “faster” to do so than to think through the problem first.

Framing it

Engineering today makes use of the basic science that has been discovered to date. Software development seldom does. Software development methods cannot stand on their own. Their purpose, from the organizations’ viewpoint, is to modify the enterprise.

Call it automation, call it business process improvement, knowledge management, whatever. You are in reality trying to replace some human aspect of the enterprise with a “system.”

In effect, you are trying to build the enterprise. This was discovered by John Zachman — the father of enterprise architecture — when he “discovered” the natural laws, the science, of enterprises.

Like Mendeleev's periodic table, the Zachman Framework, sets out the range of cells that make up the total possible set of basic elements that an enterprise is made up of.

Like the periodic table, the Framework, by itself, does nothing. But like the periodic table, it provides the production engineer a science on which to base his production “methods” on.

There are countless production plants, each making something unique, each with its own variant of production method and materials tailored to suit local circumstances, the level of skill of the engineer and the preferences of owners.

But every single one of these methods take cognisance of natural scientific laws. None of them claim to be the “only” way to manufacture a type of product. Some methods are intended to make things cheap and quick, others are intended to do the opposite. Yet, in software development, we continue to argue over which is the latest and the “best.”

Learn it

It is very important to understand the difference between fundamental science and point-in-time-place preferences. The former determines success or failure for the latter, not the other way round.

It is only when you do that you can choose and tailor the appropriate method for your organisation. And that you can truly begin to address the alignment/integration issue facing your organization, beyond the promises of silver bullets.

So, what is the simple basis of the natural laws governing enterprises?

The Zachman Framework postulates that there are six aspects to any complex system. This is because in any human language, there are a total of six and only six fundamental questions that can be asked by anyone about anything.

These are Kiplings “six honest men — what, how, where, who, when and why.”

All six questions have also got to be answered for knowledge about something to be complete. In other words, if the answer to one of more of these questions is missing, then we know that we do not know enough.

Does it mean that we cannot proceed to develop systems or build something until we have all the answers. Of course not. It just means that you have chosen to take a risk, to compromise long term interest for short term gains.

We all make value judgments throughout our lives. The engineer/builder that chooses to reduce the amount of cement in the concrete mixture does so knowingly. Perhaps there is a shortage of cement in the market, and he takes a position, given the circumstances, of making a structure that will last half the number of years, had he kept to the original specification.

Does the software architect/developer know the risks, and make a rational trade-off decision when he carries out a business analysis that takes into account only the processes (the how) and data (the what) requirements of the organization without considering the other four aspects?

Meet the man

I hope I have given you a quick insight into the power of applying natural science to your enterprise architecture efforts. Using the Zachman Framework, you can delve very much more deeply into your enterprise, and ensure that your strategic decisions and designs are based on sound engineering principles.

This is the only way you are going to have alignment, integration and all the other long term benefits that silver bullets promise but never deliver.

We do not have the space to go into detail about the Zachman Framework, but you can get this from www.zachman.com.

Or, you may be able to ask Zachman in person — he will be in Kuala Lumpur from Tuesday to deliver the keynote address for the National ICT Month 2009 conference. He will launch an enterprise architecture certification program on Wednesday.

A coffee session is also being organized where Zachman will share the latest developments on the enterprise architecture front with guests. Those interested in attending this informal talk can contact me at 010-211-7889.

• Simon Seow is a Zachman Certified™ – Enterprise Architect and has been in the IT industry for the past 30 years and is founder of Info Spec Sdn Bhd, which provides consultancy and training in methodologies of enterprise architecture and project management.