If you think it's tough to structure IT around enterprise architecture, imagine how tough it is running a business without it.
Tom reminds everyone that enterprise architecture isn't just the technology; the need for it starts when the customer walks in the door (or calls in, or visits the web page, whaatever the case may be). Processes start to kick off, requiring an "architecture of responsibility."
For example, a customer walking into a bank to straighten out a credit-card issue may encounter a series of silos before the issue is resolved. "When an organization’s systems are fragmented by arbitrary boundaries, users have to resort to error-prone kludges such as handwritten notes in order to bridge the gaps," Tom says.
Fragmented processes slow down many customer-facing situations. This is fertile ground for enterprise architects -- a set of customer processes that should last five minutes takes up to an hour.
"It’s the job of an enterprise architect to find a better way to do it, and work with others in the organization – solution architects, system designers, service designers, project managers and more – to get that better way designed and built and put into practice. Doing so would require a far broader scope than just IT. It needs an holistic view of the activities as a whole; it needs to understand not just the IT-based processes, but the human processes, and human responsibilities too; it needs to identify and clean up the kludges that people have to do to get round the limitations of the system."
This is hard work, and will surely be bogged down at points by organizational politics. But it beats the alternative -- a bogged-down organization.