Related Links

Web Seminars

Editor's note: This article was supposed to be the seventh in a series on information architecture, but the author feels that the current state of disorder around application development warrants immediate discussion. The information architecture series will resume at a later date.

A few years ago the number one obstacle to data warehouse was data quality. In addition, we (we being those of us who deal with the universal "they") always complain about business "buy-in." There is good news and bad news. The good news is these are no longer the most formidable barrier to information architecture-derived work. The bad news is, we have met the enemy, and they are in our ranks.

The "news" referred to here is the ever-increasing resistance of traditional applications development (AD) areas in information management projects. This can take the form of low-key editorializing or full-blown sabotage. Either way, there is strong evidence that AD areas have become the number-one barrier to successful enterprise architecture and information architecture projects. This is not the result of jealousies or political scheming. Rather, there are weaknesses in how information architecture teams engage the applications development area as well as misunderstanding of information architecture by management in applications development. Finally, environmental and cultural issues contribute to the actions of both the information architecture team and application's management.

First, an examination of how the applications' development area creates obstacles is in order.

Obstacle Creation

1. A fortune 500 manufacturer/distributor recognized that information management improved the value of their stock price and was a key success factor in their major markets. An information architecture project (IAP) was initiated and completed that specified all the components of IA. Implementation proceeded smoothly until the first operational applications were affected by components of the architecture - standards, methods and principles in this case.

   The only senior team member in opposition was the director of Applications Development. From day one, the project was publicly criticized and, after a public request to tone down, the harassment moved underground. The harassment even took the form of this director establishing relationships with competing vendors of the already selected information management tools and products.

   The rationale for these actions was that, "Standards and models will slow us down. Applications people can do the information management while we are doing apps, we don't need central data management - it is a bottleneck." This director was solely monitored and managed by the number of "projects" completed. He was also very close to his business users, having spent several years improving service levels.

2. A large financial services company has a very active and savvy enterprise architecture department. For two years, it has been supporting business architecture through the use of business cases and business object modeling. Business users have been ecstatic at the level of understanding exhibited by "IT."

   That is until the efforts began to, inevitably, drive enterprise application requirements, create more symbiotic projects and identify weakness in the applications portfolio.

   The application directors ran up red flags that the enterprise architecture was interfering with "their customers." The policy at this company had been to have IT business analysts translate requirements from the business to IT. According to the application directors, enterprise architecture was throwing up roadblocks to delivering application changes.

Is it Applications Development's Fault?

Before the barrage of letter writing from defensive AD directors starts, it is key to note that, in most cases, the obscuring of architecture efforts is not the result of acts of commission. Rather, there are some historical and environmental factors that create this atmosphere. Resolving these obstacles to good information management means dealing with these issues.

1. Most architecture efforts are less than successful. Let us face the facts - most information and enterprise architecture efforts have fallen flat on their figurative faces. Little business value has been demonstrated. Conversely, the operational application is constantly visible and less abstract. There is a tendency to try to put the same kinds of value statements on tactical application projects and enterprise architecture efforts. Both have "ROI;" however, the ROI is derived differently.
2. Applications development areas are not measured or "incented" on their degree of data stewardship. They, in fact, are the first to gripe about it. The CIO wants results from AD. That means service to end users, and applications that are up and running and doing what their customers have asked for. The metric of "projects completed" exists in most organizations. How many companies score their "extent of integration and leverage."
3. AD managers have an incorrect understanding of information architecture. In both of the examples above the IM department was generating business-aligned strategies. In both cases, real value added projects were proposed or even being managed. These efforts were working. However, the AD management took too parochial a view of the effort. The focus of AD needs to be widened. Granted, there are also many cases where possessiveness of development empires and internal political power struggles have overridden business sense. But most rational people who work for the same company will collaborate once the value is properly explained.

The Secret Sauce

For better or worse, it is up to the architect's efforts to figure out how to avoid the ADD trap. The CIO cannot mandate applications managers to behave. There is too much history and momentum. There are a series of actions that can be taken to intercept this issue.

1. Sell enterprise and information architecture for what it is - a value added process, not a project. A business would no more stop planning annual budgets or marketing campaigns. Why cease or allow disruptions of the programs that will reduce and manage IT expenditures? In addition, there are a slew of business drivers pushing CIOs to consider architecture regardless of what AD or anyone else thinks of it. (See dozens of prior articles on this Web site about customer, supply chain and regulatory drivers.) Selling information architecture also means being able to explain the value proposition clearly and succinctly. Use a rule of thumb that everyone in the information or enterprise architecture area should recite the value proposition of information architecture in 50 words or less.
2. Assess the applications backlog (it is usually huge). Determine and demonstrate how the information architecture project can reduce the backlog. (If you can't, your information architecture project is at fault.)
3. Include applications development on the information architecture or enterprise architecture steering committee. Address all concerns publicly, document the resolution of issues thoroughly and then publish them in an architecture newsletter - not an e-mail that will be forgotten.
4. Factor benefits for application development into the business case for architecture.
5. Create performance measure for AD based on data integration and reuse. Stop measuring AD areas by how many projects are complete. Rather, measure them by how effective the projects are and how IT costs are affected.
6. Make sure business users communicate clearly to AD and enterprise architecture teams, and that AD does not speak for business users at architecture meetings.
7. Stop allowing AD to be the only point of contact with the business. This creates a power- broker problem. This goes for business analysts, who are liaisons between IT and business personnel and can supposedly explain requirements. Architecture efforts require direct business involvement. Period. Any IT manager who feel constrained to keep business people away from architecture teams (so long as it is managed of course) is throwing the baby out with the bath water.
8. It is time for all resources that touch information value chains (which means almost everybody) to look in the corner of their paychecks. Most of the time, everyone has the same company name up there. Not "development" or "architecture" or "marketing." Functional and departmental performance targets exist so areas can be monitored and measured, but they are not the overall goals of the organization. Those goals are expressed at higher levels and must be honored before local objectives are considered.