Architect, Functional and Technical: IT's Good, Bad and Ugly?

Despite most Enterprise IT people knowing the downsides of silo-thinking in a business, many of us are aware that IT can often act as the biggest silo of all within the business of which it is part.

The ultimate objective for many is to run IT like an independent business (commercially-driven and efficient demand, supply and resource management). But there is a trick to doing so without it starting to think like a separate organisation (obsessed with its own bureaucratic processes, pet projects and irrelevant agendas). Getting the good without the bad is a challenge that has led many to embed IT back into the business units as an alternative solution.

But there are also cliques within IT itself which tend to exist whether it is centralised or embedded. The differences between the 'management' people (focused on delivering on time and to budget), the service people (focused on keeping the kit running and the lights on), and the 'content' people (focused on the solutions and the design) are obvious. But the latter in particular itself has silos. Those of functional, technical and architect.

The functional-technical divide goes way back. Even now, organisations still tend to have separate functional and technical teams. It still seems rare for anyone to really bridge the gap. One of the great characteristics of packaged apps was that they gave frameworks through which the technical and functional teams could interact (often agnostically) in more predictable, industrialised ways. This brought them together more efficiently in terms of delivery, but did little (if anything) to bring them together in mindset.

Architect-types have sometimes thought that they could cover the whole spectrum, and also aimed to bridge the portfolio-level (the enterprise view) to the application-level (the project view). But very often this just has created a third silo - the so-called ivory tower. Additionally, with many architects having come from infrastructure-planning or bespoke-development backgrounds, in the many industries dominated by packaged apps they have had additional disadvantages in building the credibility and buy-in they've needed.

However, today's increasing focus on SOA and in general architecture above the level of the project, driving cross-project synergies and initiatives requires that the three viewpoints work together. Take composite applications for example. How can (what are by definition) composites of data, function and technology assets, mixing packaged and bespoke, be put together scalably without united functional and technical views? And how can a portfolio of them be managed without an architecture view across them that balances the delivery-proposition to each project, with the customer-proposition to each part of the business, and the ongoing ownership-proposition to the enterprise as a whole?

None of these issues are (in principle) different from those of our recent pasts, but this is the first time that the very value proposition of the approaches themselves have been contingent on these viewpoints being able to work together. And making it stick.

Technorati Tags: Enterprise IT IT Excellence Enterprise Architecture EA Service-Oriented Service Architecture SOA Composite Applications