Escaping the EA stereotype

Image: Escaping the EA stereotypeIn this article from PwC, we explain how enterprise architects need to reach beyond their standard toolsets to methods that go beyond recordkeeping, IT asset management, and fractionalized governance.
 

Download Technology Forecast 2010, Issue 1 for the complete article


To seize this opportunity, EAs need to reach beyond their standard toolsets to methods that go beyond recordkeeping, IT asset management, and fractionalized governance.

It’s a story many C-level executives can relate to: A multinational manufacturing company, in business for decades, has growing pains. It has been stuck in the business model of its early years, when it was run by a core group of engineers focused on step-by-step product innovation at all costs. Now far larger and more complex, the company has little visibility into its processes, its relationships with suppliers and customers, and what it needs to do to move forward purposefully and efficiently.

Executives at the multinational know where they need to be, but they are frustrated about how to get there. They know that their business processes and IT infrastructure must be in sync. However, they face many familiar challenges in achieving that objective: changing corporate culture, lack of communication among stakeholders, no holistic view of systems and the linkages between them, staff pulled in different directions, and an incomplete understanding of the importance of enterprise architecture.

In companies like these, transformation initiatives are an opportunity for enterprise architects (EAs) to become involved and add value in a new way.To start this process, EAs need to be pragmatic from both an IT and a business perspective during transformation efforts. Although most EAs have traditionally focused on the IT side of things, that’s not the current trend. A good EA these days takes a holistic view across business, information, application, and technology dimensions to look for potential areas for improvement (such as costs, efficiencies, and better customer engagement, among other things).

For example, when assessing high customer churn at a telecommunications carrier, a good EA would first look at business processes such as order taking, fulfilment, and billing, and then review how well call centers, logistics, and customer relationship management (CRM) systems support these processes.

It could well be the case that the technology is fine, and the real problem is poor training in the call center. Conversely, it could be an IT problem—perhaps customer data are fragmented or the systems are old and take too long to respond to queries.

Architecture helps EAs start at the business activity level and then move down into business processes to try to find the root causes of underperformance. Only then does improvement become possible. Once an architect understands the root causes, developing a good to-be state becomes an effective next step.

Overall, EAs must think outside their traditional frameworks. They need to reach beyond their standard toolsets to methods that go beyond the recordkeeping, IT asset management, and fractionalized governance that relate only to applications and technologies.

More importantly, they need to use expanded toolsets in a way that’s helpful for long-term evolutionary change, not short-term fixes. The problems of companies like the multinational manufacturer didn’t arise overnight. EAs can’t help fix those problems simply by filling in cells in a modeling tool, running a series of diagnostics, and generating diagrams that spell out the problems in EA terms. EAs need to communicate their findings clearly, succinctly, and when they’re needed, preferably in graphs that are easy to understand or in simple visualizations. This article explains how.

Download Technology Forecast 2010, Issue 1 for the complete article