The haunting continues. Ghosts of information architecture (IA) past roam the halls of corporate America. They visit leadership at fitful late night hours replacing deep sleep with buzzing texts, "E-commerce site down; transaction deadlocks, no ETA!" The ghastly apparitions defy sequestration to evenings. In broad daylight, decisions made in past projects bring our supply chain systems to their knees, multiple systems from several vendors, of course. Wraithlike business processes rattle about like Jacob Marley tormenting Ebenezer Scrooge. The chains forged in implementations past dragging behind. Fortress silos of data, suboptimal Web design, multifarious physical infrastructures, excessively coupled, noncohesive code and SOA with little reuse potential add to the clatter. What is the solution? The key is defining a clear model to deal with information. Good IA delivers a core multidiscipline approach toward data, applications and systems driving usability.

Consider the allegory of Sara Winchester. By the Victorian era, murderous capabilities of Winchester rifles amassed her fortune. Despite affluence, deep regret impaired Ms. Winchester. A physic medium consulted, "Build a great mansion and the slain will forgive." A four-decade project ensued. The project began and ended without a blueprint. A bonanza of work ensued for carpenters, plumbers and every tradesman imaginable. Cutting-edge, innovative technology defined the project. Breakthrough advances in heating, plumbing, lighting and elaborate detail are ever-present in Sara's reparation to the dead.

Not surprisingly, the lack of architectural planning led to some interesting "features." The 160-room mansion has multiple staircases to nowhere. Many fine Tiffany windows bedazzle the visitor, despite being set in the floor. The Winchester Mystery House is an archetypical example of a battle fought without a plan.

IT leads business through the battles needed to thrive. However, has IT planned these many pitched battles? Is IT campaigning toward improved profit through reusable, consistent architecture? In candid moments IT confesses, "Heck no." Has a bonanza of work and rework ensued? Many a general ledger would say yes.

Contemplating IA from within the walls of one's own Winchester mystery house is a common experience. Often, there is no IA plan. Is there a slogan? Perhaps the motto is buy, implement, depreciate, run for 5 more years and then repeat. Perhaps the modus operandi implements best-of-breed technologies on a project-by-project basis. There are many creeds, and perhaps the catchphrase of the day does not include IA. This does not prohibit inserting it. Regardless of the lack of IA, set a new course.

To begin, let IA tollgates exist in every phase of the software development lifecycle (SDLC). Projects are the key. Consider the ANSI Standard definition of a project: "A project is a temporary endeavor undertaken to create a unique product or service."1 By definition, something will appear for the first time because of a project. Add IA at inception. However, carefully construct the definition of IA to avoid calamity. After all, Sara Winchester was an architect.

Definitions of IA Proliferate

The creation of blueprints is a salient definitional thread. Begin with a concept, a model and a plan. Plan simply. Create and improve architecture with each project. Show that each project has thought about and has improved organizational architecture. Leave blueprints after each project as artifacts of success. Projects in the initiation phase will be pleased to have these artifacts available, especially as the last project funded. However, beware of excess. Overburdening any one project with a global IA implementation task invites failure. Hit the essential IA points at outset. Migrate incrementally toward an enterprise architectural blueprint. Let the blueprint consist of straightforward building blocks.

Begin with three building blocks: data, applications and systems architectures. Select the basic blueprinting tools for each block. Some familiar coins for data architecture are entity definitions, entity relationship diagram and entity-to-business-function mappings. Establish the foundations of application architectures on listings of all applications, matrix classifications to their business functions, appointment of Subject Matter (Business) and Domain (technical) experts, and analytical tools focused on usability and user experience. Deliver Services by mapping a canonical model across process, data, and applications. Data domains with defined ownership drive higher reuse as logic binds data, users and hardware. Systems architecture definitions arise from understanding physical infrastructure and distribution patterns of data and applications, and their business domains. Ask, "What is on this physical infrastructure? How is it backed up, recovered, replicated, moved and presented to the enterprise." IT is very familiar with these architectural methods and tools.

True, every company has an IA. The concept of blueprinting the enterprise IA as data, applications and systems building blocks is mature. Alas, not all efforts are equal, and sadly, mature systems decline. Nevertheless, each fundamental block has champions. For example, the Data Management Association (DAMA) is now creating a detailed Data Management Body of Knowledge (DMBOK). The DMBOK, a work in progress, offers a clear framework to understand the functional areas of data architecture. Generally, defining each architectural building block is essential. However, the union of all three blocks is indispensable and requires program coordination. Consider.

The E-Commerce Crown Jewel Project begins. The data architect delivers normalization, banishing data redundancy and waste. However, the application architect laments slow response times due to a five-way data join frequently called and summarily stuffed across the enterprise service bus. All this causes grief for the systems architect, now fending off demands for new hardware to speed up the bus. None of the three holistically observes the terrain. Forgetting that balance is crucial, they serve one domain. However, the whole is more than the sum of its parts. Endeavor to proportion all three building blocks by integrating blueprints. Enter the information architect offering guidance to the portfolio of projects. Most welcome the direction.

Architectural tools and good intentions stimulate technologists. However, the inception of an IA journey begins a descent to fear for some in the organization. Why fear?

Information architecture roadblocks include:

  1. Past enterprise initiatives,
  2. Architectural mission and plan,
  3. IA champions,
  4. Expense,
  5. Education,
  6. Business departmental barriers, and
  7. Starting.

The number-one hazard? "We have heard this before." Enterprise projects instilling architectural discipline are not new. There is a record of accomplishment. Massive initiatives branded frameworks, models or governance-implemented IA to good effect. In some cases, IA beneficiaries rout business competitors. However, any group of endeavors presents a spectrum of results. Negative results generate more buzz than success. Architectural initiatives for the sake of style have a legacy of good, indifferent, and awful results. Prepare to address the bad. Past projects to establish IA in organizations reek of profligate scandal. History proves blind acceptance of overhead in execution, expense and education unwise. Obsequious compliance to architectural dogma dilutes ROI. Think of a costly blueprint for a house never built.
Have an executive mission and a plan to build. The mission is to embrace IA and deliver artifacts necessary to advance and diffuse knowledge. The plan is a project portfolio depicted as an architectural roadmap. Implement IA gradually and progressively on a project basis. Incrementally add to organizational capital in the area of IA and always leverage existing artifacts. However, how will this process ever start? No one wants to be the first penguin in the water; "There are sea lions in there!" "My project has deadlines." "We do not have time to do this!" How will an organization facing the bottom line be able to focus on architecture?

Sort the penguins on the ice. Find the right projects and the true champions of the cause. Find the people that have an axe to grind with bad architecture. The leadership of impacted departments knows the symptoms. Data quality is poor. Financials are wrong. Sales numbers are missing. Reporting deadlines go by. Contract development takes too long. Point-of-sale transactions do not support the business needs. Sales figures coded as "general" give no insight into trends. Customers get the wrong products. Changes to systems take forever and require multiple late-night interventions by IT. There is no timely information on the business, operations and competitive results. It is easy to pinpoint dysfunction and to tailor the description to an organization. Just ask! Take notes and amalgamate results. Departmental leadership needs to see the big picture. Gathering a consolidated view of the opportunities sells IA.

The consolidated business process view sends ROI leaping off the page. Mature IA literally turns failures 180-degrees toward success. Realistic and persuasive ROI projections transform departmental leadership into IA champions. Now all the penguins want to swim. IA is a good idea. We all knew that. Exorcise these ghosts! The translation from a good idea to victory begins.

Having identified projects as the ambassadors of IA to our organization, it is incumbent to offer guidance, organizational support, education and expertise. Expertise is the adhesive. Experience, however, will keep us from being stuck. Make sure data, applications and systems architecture sages contribute to the IA attack plan. Use good judgment selecting the inaugural artifacts required in each phase of a project's SDLC. Artifacts prove their merit by showing obvious high reuse value. Drop artifacts quickly from the SDLC if selection mistakes occur. Offer lightweight training for initial explanation of new tools, and offer a more heavy-weight version in more remedial situations. Share the roadmap to ever-increasing IA maturity at the outset of every project. Do not forget to include the "You are here" arrow in the discussion. As this process matures, the ghosts weaken, IA delivers and dividends materialize.

Reference:

1. A Guide to the Project Management Body of Knowledge (PMBOK Guide), Third Edition, Project Management Institute.


Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access