The other day I was at a review of a company’s plan for DSS and analytical processing.  I heard something that piqued my interest.  When the question was asked – “what architecture do you follow?” the client responded  – “we have Microsoft for our architecture.”

I have often used Microsoft and its products. I have a great deal of respect for Microsoft and their product line.  But I never considered Microsoft to be an architecture.  Microsoft is a product line.

If there were a pervasive product it has to be Microsoft.  There is no doubt that Microsoft has products aplenty for the desktop.  In that regard Microsoft is truly rich.  But to consider Microsoft to be an architecture is not something I have ever considered.  In my opinion, Microsoft has plenty of products, but it is not an architecture.

So what then constitutes an architecture?

One feature of an architecture is that the architecture addresses one basic problem.  An architecture is focused.  While Microsoft certainly has lots of features, it is not focused at solving a single problem.  It is focused on solving a whole set of problems.  To that end Microsoft often allows the same issue to be addressed in multiple ways.  But Microsoft is not a soup to nuts supplier for any particular problem.

Another aspect of the focus on one problem is the fact that the problem is addressed from the inception to the conclusion. Microsoft is good at addressing problems and issues around the desktop. But looking at a larger problem of running transactions, integrating data, and creating analytics Microsoft is good at only parts of the problem, not the entire problem. It is placing Tiger Woods in a decathalon. There is no doubt that Tiger would dominate any golfing competition. But when it comes to the shot put, the pole vault, the high hurdles and the javelin, Tiger would most likely not dominate.

Another aspect of being an architecture is that of integrating with a wide variety of technologies. Microsoft is good at integrating with itself, and a few select outsiders. But when it comes to interfacing Microsoft with IMS, Oracle, VSAM, IDMS. Model 204 and a whole host of older technologies, Microsoft really comes lacking. In fact one wonders if Microsoft even knows that they need to interface with those technologies at all. (One can put one’s head in the sand and say that there is no need to interface with the technologies of yesteryear. But the fact is that there is valuable data tied up in those older technologies. To not be able to access and manipulate those technologies is to not be an architecture.)

Yet another aspect of being an architecture is that of being able to handle industrial strength volumes of data. Rightly or wrongly, when it comes to large amounts of data, the world trusts UDB, Oracle, and Teradata.

Still another aspect of an architecture is that an architecture can handle data throughout the life cycle of data. The strength of Microsoft is that it can handle data well for the here and now (and that certainly is important.) But when looking over the full life cycle of data, Microsoft’s support of data across the full life cycle of data is questionable.

And another aspect of being an architecture is that all types of data are needed. Microsoft certainly has metadata. But when one looks for the enterprise perspective of metadata, one has a hard time finding it in Microsoft.

So there are major reasons why Microsoft is a good technology company but why Microsoft is not an architecture.

So where does one find an architecture?

Take SAP, for example. SAP is an architecture. SAP solves the problem of data management from soup to nuts. From the initial capture of data through an application, to the processing of data within the application, to the transformation of data from its application format, to the analytical use of data, SAP is a real architecture.

Consider this. SAP supports application processing across a very wide variety of applications. Microsoft supports relatively only a very few applications. When it comes to comparing the applications that SAP supports versus the applications that Microsoft supports, it is like comparing the New England Patriots to the local high school football team.

Now consider interfaces to external technology. You can get all sorts of data into SAP. You can get IMS data, IDMS data, VSAM data and a whole host of other data into SAP. SAP has its own technology for that kind of processing. In addition SAP works with different ETL vendors, including the recently acquired ETL technology from Business Objects. So SAP is very much able to interface with other vendors. Furthermore SAP knows why it needs to make such an interface.

SAP can handle large volumes of storage. SAP has the capability through its own core technology to handle large volumes of data. In addition SAP has new advances in near line storage and BIA that allow it to manage truly industrial strength sizes of data.

SAP has long been able to handle archiving of data. SAP recognizes that data has a full life cycle, and that includes the management of data as data ages. It is difficult to call a technology an architecture unless the full life cycle of data is taken into consideration.

SAP has long supported metadata. And when it comes to enterprise wide metadata SAP has master data management. SAP understands the need to support all sorts of data, like an architectural vendor needs to do.

But the most significant test of whether a product and a product line is a technology or is an architecture is the test of whether a company supports a full line of processing. SAP supports all the needs of data – from capture, to application processing, to corporate transformation, to analytical processing. SAP solves a problem. Microsoft provides technology at the desktop.

When I hear someone say – “Microsoft is an architecture” – I know that that person has not considered the full range of their needs. Or it is possible that their needs are found only at the desktop. Once outside of the desktop, it is really hard to consider Microsoft to be an architecture.

About the Author

Bill Inmon, the father of the data warehouse concept, the corporate information factory, and the government information factory has written 47 books on data warehouse, data base, and information technology management. His publishers include John Wiley, Prentice-Hall, and QED. His books have been translated into nine languages. More than thirty of his books have been book club selections. In addition Bill has written over 750 articles for trade journals such as Data Management Review, Byte, Datamation, ComputerWorld, and many others. Currently Bill has a newsletter with b-eye-network.com that reaches 55,000 people. Bill founded Inmon Data Systems, a company that reads and manages unstructured data - emails, telephone transcripts, documents - and processes them for inclusion into a structured data warehouse. In addition IDS creates visualizations for unstructured data. IDS has technology that crosses the bridge between unstructured data and structured data, currently protected by seven patents. Bill can be reached at BInmon@BillInmon.com