10 years, 10 months ago

Office Apps Are a Shaky Foundation for Enterprise Architecture

bg outline

With something as big and complicated as the entire enterprise, it’s not uncommon for customers to look for help after seeing an enterprise architecture (EA) effort collapse. One of the most frequent reasons their efforts crumble is that they tried to build an enterprise-scale architecture using office productivity tools such as Visio, Excel and PowerPoint.

Any real EA veteran will tell you that office tools are not adequate. They produce little more than hundreds of pages of poorly written, vague and inconsistent descriptions of applications and infrastructure in Microsoft Word; megabytes of spreadsheets listing Configuration Items in confusing, out-of-date, illegible shorthand, and of course the PowerPoint presentations with cute graphics, fancy fades and transitions but precious little reliable, standardized information the organization can trust.

These applications give users way too much unnecessary creativity for a good EA effort. They enforce no standardized formatting of enterprise information, nor do they enforce repeatable processes for creating the views. They don’t govern how best to present the important information and, most importantly, what irrelevant information to leave out.

For example, we’ve seen many cases where different architects created detailed application models using Visio, and then had to spend many hours reconciling the differences among their models. We’ve seen the same with Excel spreadsheets, where skilled and expensive EA experts waste their time not only comparing data, but becoming “spreadsheet jockeys” managing details and debugging formatting issues rather than leading and advising business transformation efforts.

While they may seem inexpensive, trying to create an enterprise architecture using only office productivity tools is like tying a bird to a brick: It may get off the ground, but it won’t get very far, and the fall can be very messy.

If you must use such office productivity apps, impose consistent, understandable guidelines on their use wherever possible. At the very least, this means common templates for how documents, spreadsheets and presentations should be created and organized, based on consultation with your business users and technical staff to understand what critical information they need. Carefully and clearly define the precise information that must appear in each field, and limit extraneous information to a single “notes” or “more information” field for each data element you are tracking to avoid confusion. Finally, communicate these requirements clearly and often to everyone on the EA team, and develop processes that ensure information about the data elements is kept current.

Of course, we feel it’s easiest and most efficient to use a tool such as ours at Troux that comes pre-populated with the proper fields, allows you to validate and normalize data in real time, and provides the workflows and best practices required to manage and make proper use of that information in appropriate reports and visualizations. But if you absolutely insist on going the “Office Apps” route, at least limit your team to the use of one application (usually Excel, since its rows and columns structure gives you a head start on organizing your information.) Trying to make sense of inconsistent information in one application is bad enough; trying to reconcile it across multiple forms of documentation is absolute madness.