Delivering SOA Across Projects: Dealing with Shared Dependencies & Risks

I posted not long ago about professionalising the planning and delivery of SOA initiatives, making realising them more than just a gamble based on theory and good intentions.

One of the biggest pieces of this puzzle often seems to be dealing with the project delivery issues. The industrialisation of SOA if you like. The key issue is that many are not ready to deal with the shared and cross-project dependencies, the additional technology complexities, and the cross-project risk mitigation demands that enterprise-level SOA creates. Such issues create havoc with the conventional project delivery mechanisms and mindsets of the moment, but without project delivery being on-board, an enterprise-level SOA is extremely difficult to scale up to the level required for it to start paying off.

IT Project Delivery
Modern IT delivery (pre-SOA) practices that combine both robust project management and proper diligent delivery management have improved significantly over the incarnations of the 90s and before. They're particularly stronger in areas like governance, visibility and indeed success rates, learning lessons from mistakes of the past. However they've been shaped by a diet of scope definition, issue identification, risk mitigation, and industrialisation of production in traditional systems-centric world. Where each system and project has its own direct business case. Of course its not perfect, for example the delivery models of many are not as mature as they should be in how they effect global sourcing and production in order to take advantage of off-shore production whilst maintaining quality and efficiency. However, ignoring globalisation, many of the basics of today's delivery get turned on their heads by cross-project SOA initiatives.

Real cross-project SOA introduces dependencies between projects who are sharing services, coexisting in environments, or reusing central assets. It also generally means that issue resolution and risk mitigation within a project is no longer within that project's own hands. And in seeking to optimise the technology across projects, it mostly means that each project is sub-optimised, increasing the 'number of moving parts' of technology (and therefore generally the cost) beyond what is needed to realise the project's business case. A situation which often isn't exactly welcomed by the leadership of the projects concerned. And of course there are many more such changes, but you get the idea.

Some organisations have laudable ambitions for the use of architecture in reversing years of IT duplication, proliferation, conflicts and silos that business-unit-centric or project-centric technology deployment has caused, but they embark on it without a proven or complete plan as to how to deal with the road-blocks, or handle the stakeholders who's incentivisation or behaviours lie elsewhere.

1. Project Effort and Cost
For example, you have the additional factors in estimating the effort required in a project and allocating its cost. Even where a project has agreed to take on the additional technologies and development costs of the new middleware (e.g. ESBs) needed to effect SOA it will need more extra budget provision just for the dialogue needed with the central team doing the architecture and technology-usage governance (be they an EA team or called something else), and participate in the joint service designs and testing. Let alone the change control needed if a project has to comply with a late emerging technology standard, or extra regression testing required because of a change request in a parallel project which shares services. And this is on top of the actual effort taken to build the services that they need to build, and effectively feels to the project concerned like time that is not value adding and is not being spent getting on with the solution.

As often is the case, a commercial contract between two parties focuses attention on things that would otherwise be hidden, and if a 3rd party implementer is involved in delivering a particular project, these additional provisions will need to be surfaced up front, and potentially put into the contracting. That's not a nice conversation to have, but infinitely preferable to a much later conversation justifying changes in budgets when it's too late to do anything about it.

2. Design, Configuration and Release Management
There are also the additional complexities of service design, configuration, and release management in cross-project delivery. Firstly, the environments. On one hand there are more technologies that require environments (to develop->test->cut-over), and then all the technologies (new or old) require demarcation between the (develop->test) environments within their own project's control, versus the (testing->cut-over) environments in common shared environments.

Then secondly there is the new design governance process required to collectively agree a shared design that multiple projects work towards, to manage requests for changes to it during development and when its live, to coordinate integration of parallel work-streams, and to sign-off completion of delivery to the pre-agreed design. That last one is particularly troublesome as many 'design committees' that may exist around an SOA initiative may take on the design sign-off responsibility, but are often not resourced or mandated to sign-off delivery to the design. And yet without that ability the projects are at the mercy of factors outside of their control (and timeline) for sign-off, which may be incompatible with the obligations they have to the business, and their business cases.

3. Risk Management
Even with an appropriate configuration management process, and the appropriate bodies with the appropriate mandate to play the roles in it, it still is more than a little problematic to deliver federated cross-project SOA. Particularly with parallel delivery (as opposed to sharing only assets that have already been deployed) which is probably the most ambitious SOA delivery model.

Management of the risk profiles involved causes significant uncertainties for the commercial models each project is using to manage its cost. Fundamentally the budget that any project uses will be based on a certain scope, certain assumptions, and certain known risks for which it will allow contingencies. Whether there is a 3rd party prime contractor involved, 3rd party subcontractors, or only internal heads involved will affect what type commercial model is used, and therefore how the cost and contingency are estimated. But whatever the case, the project will be carrying a certain risk profile that it will look to manage so as to keep its commitment to deliver.

Of course the dependencies of the project on central activities, on existing seemingly vague assets, and on other projects activities, creates additional risks that existing techniques find it difficult to identify, and which are not within their control. This means that projects are potentially exposed in carrying risks that they find it difficult to estimate contingencies for, and that they are unable to mitigate.

Shared Services (...for Delivering Shared Services!)
But these are of course not really new problems. And they're not really peculiar to SOA. They are an aspect of executing on any shared initiative above the level of a project and business unit (BU), which is dependent on the project or BU to realise it, and therefore applies across those projects and BUs. Ultimately this boils down to being an aspect of achieving objectives across reporting lines, in a situation where those objectives include indirect (federated) business cases, in addition to the (projects' own) direct business cases.

The techniques that has most successfully been used to solve similar problems before in previous generation of IT are simple operating model concepts widely used in other areas of business, taught in most b-schools, and written about many times. They're shared services (, although I'll use the old IT term 'centre of excellence' here to save confusion between the shared services in SOA delivery from the the shared services of service oriented architecture itself).

A centre of excellence (CoE) or competency centre for SOA delivery allows the projects to all sub-contract the production of the (SOA) services to that CoE and therefore to exchange the risk that they can't manage themselves for a service-level agreement (SLA) that they can manage to. It also allows the CoE to manage the internal dependencies between the different requests being made of it, formalising and managing th change on contracts with its customers (the projects) so that it can coordinate the cost and SLAs to the risk it carries at any time. It also of course allows the CoE to drive centralised knowledge management, developing its own capabilities and professionalising its own working practices using its own revenue stream, and gaining from the economies of scale on the supply side that no one project could have experienced on its own.

Its great that its becoming acknowledged that an enterprise-level architecture capability (although often not a traditional EA group with a traditional EA framework) is key to being able to drive cross-project technology and architecture strategies and improvements. In such scenarios that EA capability is in some ways acting like a shared service for the design phase (and to a more limited degree, for the preceding demand management phase). But that is only a part of the lifecycle. A shared design is much harder to make it into reality without some level of shared delivery (construction) and shared operations (run and support). Sounds simple when it's said like that.

Technorati Tags: Enterprise IT Project Management IT Delivery Shared Services Center of Excellence Competency Center Enterprise Architecture SOA Services Architecture Service-Oriented Architecture

Survival of the loudest?: 'Social' evolution in Enterprise IT

Last year (after a recommendation from Nigel Green) I finally got round to reading Lila by Pirsig (probably better known for his previous book 'Zen and the Art of Motorcycle Maintenance'). It contains some great thoughts and insights that, whilst written for a totally different purpose and audience, I found very interesting and relevant to enterprise IT. Particularly to enterprise processes, systems, data and architecture.

Bear with me as we go a bit abstract here ... One of the models that he proposes is that the world as we know it is made up of series of 'systems' constructed one on top of another.

-He identifies the inorganic systems (how atoms, molecules, materials etc work) to be the first.
-Then he identifies the biological systems (how cells, organisms, life etc work) to be next, existing on top of the inorganic systems.
-Then he identifies the social systems (how individuals, groups, cities, cultures etc work) to be next, existing on top of the biological systems.
-Finally he identifies intellectual systems (how ideals, concepts, intellectual values etc work) to be next, existing on top of the social systems.

One of the several things he does with the model above is to point out that whilst evolution is well accepted in the biological level, it is rarely seriously considered at the social and intellectual levels. He proposes that the concept of evolution is just as appropriate in describing the change in the patterns seen in the social systems and the intellectual systems of the world, as it is to the biological ones.

He suggests that the patterns in each level have evolved on top of the patterns in the level below. That they have not been designed to serve the systems in the level above. Therefore he proposes that the social systems (e.g. cultures, cities) have evolved on top of biological patterns (e.g. man). They have not been predetermined to underpin the intellectual patterns (e.g. intellectual ideals). He proposes that social patterns may have been retrospectively formalised to support intellectual values (such as ideals of a culture), but actually the intellectual values themselves evolved from the platform provided by social patterns. In turn, he proposes that intellectual systems have evolved on top of social systems, not vice versa. Clearly, although this is not unintuitive, it challenges certain conventional wisdoms that cultures are the result of the intellectual ideals and cities are the creation of man.

You may wonder why I am describing something so metaphysical on a blog about Enterprise IT, well there is method in my madness. The example he gives about how people often consider cities to be the creation of man, that have been planned out and created as some kind of master plan in the heads of the individuals involved is a very interesting one. Pirsig rejects the idea, describing how his model suggests that actually the city at any point has evolved on top of the biological patterns involved, governed by the value systems involved, and the ways they have interacted. He rejects the idea of grand predetermined design of a complex social system such as a city (although these are my words not his).

Given how often Enterprise Architecture and IT planning are compared to city planning (inc. by me, Todd, & Villas to mention a few recent blog postings alone) it should be interesting to anyone involved in IT strategy or architecture. The equivalent of the concept in the Enterprise IT world could be that an Enterprise IT estate is not the creation of the technologies or the people involved, it does not exist as a result of any master plan, but is a complex system that has evolved as a result of the value systems that have interacted.

The obvious activity for a rational IT chap is to consider what would be the actualisation of Pirsig's models in the enterprise IT world, using an Enterprise Architect, IT planning or Portfolio Management viewpoint. Maybe the inorganic level could be the technology infrastructure, both software and hardware. Maybe the biological level could this be related to systems and data. Maybe the social level could this be the work-practices, policies, and networks/communities. Maybe the intellectual level could be the business objectives, models, and processes.

However rather than get too caught up in debating the potentially academic details of the mappings, I'm more initially interested in some of the dynamics of this model. It's not like the applicability of top-down 'intelligent design' in Enterprise IT has never been questioned before after all, but rather than just practitioner's scepticism, this gives alternative hypotheses to consider.

Of course there's enough material in such a consideration for a book in itself, but one of the dynamics that jumped out at me right away that I thought I'd mention here was that concept of social systems evolving on top of biological ones. If there is an enterprise IT equivalent of the biological level, then I suspect it's comparatively well understood and catered for compared to the social level. I have often been of the opinion that social dynamics and value systems are very badly understood in Enterprise IT, much to its detriment. Management science is better (although far from perfect) at considering the social systems that make up the organisations we work in or work with, but such matters often seem to be almost a complete blind-spot to IT.

The biological evolution of IT systems we can appreciate (although many organisations struggle with managing it), and the intellectual evolution of business models and objectives we can also appreciate (although again many struggle), but the conventional IT concept of 'the users' and the tools of functional requirements, flow-charts, use cases etc always feel like vaguely prehistoric blunt instruments for considering the social systems of an organisation. Extrapolating the concept that social systems 'evolve' on top of biological systems, based on the interaction of the value systems (and which proliferates most effectively) seems to suggest to us that we should have a far better way of describing the different communities, networks, ownerships, motivations, behaviours etc in an organisation around its use of, and opportunity for IT. One might even over-simplistically describe it as the politics around the use of IT.

Of course the re-popularisation of the internet ideals as part of the trend often referred to as Web 2.0 has brought a lot of focus to the ideas of community in consumer-focused IT, including blogs, tagging, wikis, inclusive economics etc, and many varieties of social software. The Enterprise 2.0 initiative of Andrew McAfee and others has brought an interesting perspective to how these technologies could and can be applied into enterprise IT scenarios. But even though these new technologies will very likely be important going forward, the dynamics of the social systems around IT of course apply to all system-types and all technology generations, not just social software. It can't be the preserve of a new generation of enterprise technology alone.

Sidebar: Pirsig also uses some excellent metaphors about academics that are scarily applicable to the IT industry. For example he talks about 'restaurants with 300,000 page menus and no food'. That reminds me of far too much of IT than is healthy. Another that stuck in my mind was his 'highways full of drivers too busy telling each other how to drive to actually get anywhere'. If there is an activity where that applies more than in IT then I'd love to know which? Other than politics itself of course.

BTW: I'd be interested to see what some real Pirsig experts think of this misapplication of MoQ. But please be gentle, I'm conscious that it's not exactly a pure representation...

Technorati Tags: Enterprise IT Web 2.0 Web_2.0 web-20 Enterprise 2.0 Enterprise Architecture Systems Architecture Information Systems Pirsig Robert Pirsig Lila MOQ

Placing Your SOA Bets: Making Architecture Initiatives More Than Just a Gamble

Reading this great post the other day spurred me to blog about the 'SOA lottery' that seems to be all too common.

I don't think I've ever met a decent project or delivery manager who would take on a remit without knowing what it took to be successful at it. However, in IT strategy and architecture the opposite can often be true. Once intellectually wedded to the elegance or abstract value of a new approach or principle it seems that for some the architectural approach itself becomes the goal, rather than just a means. And in many cases, the 'remit' to make this happen is taken on blindly. And by implication, without knowing what it will take for an initiative around it to be successful. It becomes almost a gamble ... will it pay off ... will it work ...

I don't believe that it is knowledge of the technologies or standards that is lacking, and it's not knowledge of the architectural frameworks or methods that is lacking either. It is a lack of knowledge of what it takes for an architecture or strategy to be perceived as being successful by all the people whose role is affected by it, or who otherwise have an interest in it. Without this it won't actually deliver anything. It will just be a good idea. And as one of my clients had on their whiteboard last week - good ideas + no results = bull....

Look at SOA for example. Even when its value is defined well (and that is rare) it is still not equally valuable to every type of project or requirement. In addition it changes the game for various IT and business people who probably don't care much about architecture. For example, IT operations, IT project delivery management and IT business relationship stakeholders to name just three. It introduces new processes, risks and dynamics into their roles that change the way they need to behave, and what they will need to prioritise.

Anybody who's been involved with traditional IT-enabled business transformations will recognise that stakeholder and change management are two of the most critical activities in making the initiative successful. However good the objectives of the project, or however clever its design, without stakeholder and change management it will not be a success. Without participation from the stakeholders it won't be delivered successfully, and without transformation of the working practices it won't be used successfully.

And yet it's actually more complex than that for an architecture initiative such as one based around SOA to be successful as the value proposition applies across programmes, rather than within one. For them it isn't about a 'direct' business case (like most business transformation programmes) whereby the cost savings or new functionality delivered by a project realise the value proposition. Instead with these types of architecture initiatives the value proposition is indirectly delivered through the effect it has on other projects, or more accurately the effect it has across an organisations portfolio of projects, systems and technologies.

Of course this makes the success of such architecture initiatives dependent on stakeholders who are not architects, and whom likely do not appreciate the ways that the architecture will affect what they do. Moreover, they will probably resist the way it will likely affect their own initiatives' business cases.

Rather than make this post longer I'll blog separately on stakeholder and change management for architecture initiatives, but a good start is to consider which horses to bet on so that the chances of success are maximised. The key question there is where the architecture style (e.g. SOA) is independently valuable, where is it marginal, where it can be used implicitly, and where it's positively unjustified. This needs to balance the conceptual strategy viewpoint that IT architects are often strong on, with the pragmatic viewpoints of the delivery stakeholders, the maintenance stakeholders, and the business ownership experience.

On that topic I was interested to see Nick Malik's recent post on 'JABOWS' that suggests it is to do with which business process the solution is related to. In particular how often the business process in question occurs, and how often it changes. I like this model but I'd suggest there should be a couple more variables beyond these first two to give the level of practicality that can help you differentiate and plan - but it's far from an exact science at this stage.

Without meaning to overuse the gambling analogy, I believe that knowing this is the key first stage to placing the right SOA bets in an organisation. And as if by magic (!) it's also the topic of a session I'm running at the Open Group's Enterprise Architecture conference in Paris on 24th April - I'd welcome any views of what would be the most important aspects to work on.

Technorati Tags: Enterprise IT Enterprise Architecture EA Service-Oriented Service Architecture SOA Open Group The Open Group Open Group Paris 2007

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

The Inmates Taking over the Asylum? Traditional Data Management Meets Web 2.0

What does the way the public internet is evolving tell us about how Enterprise Data Management might change?

After having presented on these questions recently at DAMA Europe, I've been contacted several times about running an independent follow-up workshop in the London area in the early part of 2007 to work through some of these issues. Anyone who'd be interested in such a workshop, please drop me a line through a comment, link or the email address on my profile page.

Enterprise IT has always looked to improve efficiency through industrialisation and automation. This has often meant standardisation, centralisation, and consolidation were/are used as methods of enabling this. Enterprise Data Management has been no different and has generally followed this path. Whether you're thinking about (1) relational databases and data modelling, whether you're thinking about (2) data warehouses, the CIF and business intelligence, or whether you're thinking about (3) metadata management, business activity monitoring and corporate performance management ... all generations have held standardisation, centralisation and consolidation either at their core, or at least relied on it to a significant degree.

But outside of the enterprise, the internet of enthusiasts and consumers has had rather different dynamics. Rather than automation and industrialisation, its key objectives have tended to be more like access and collaboration. This difference has enabled interesting emergent innovations in the internet that enterprise IT has been able to absorb back into its own practices.

This applied to the original world-wide web and the eCommerce wave where the mass access to information at almost zero cost enabled new channels. New channels for organisations to interact with their customers and suppliers, new ways for systems to interact with their users, and new ways for employees to find and get at information hidden in their organisations' islands of information.

It's interesting to think about what the current wave of evolution in the internet (generally referred to as Web 2.0) might mean. One of the characteristics about what is known as Web 2.0 is that rather than the web primarily acting as a new channel providing greater access and cheaper communication, the emphasis is on the web being the platform itself, providing a basis for new levels of collaboration and cheaper participation.

For the Enterprise Data Management world there is an additional focus in this. As with the original web generation, although the channels available and information access grew, the data was generally still 'owned' in the same place it always had been. However now, the Web 2.0 evangelists and analysts talk about the user controlling their own data - which should grab the attention of all professionals involved in enterprise data, as it's a big mindset change from where things have been in the enterprise.

There are many interesting patterns in Web 2.0 that warrant analysis for clues as to how enterprise data may evolve. The Long Tail for example is very relevant, as enterprise data's current techniques and approaches are generally very expensive in terms of labour, time, and politics and so can only be applied economically (if at all) to the most common pieces of shared data, and not the huge amount of other data. The dynamic bottom-up network effects and the emergence that follows fosters behaviours and insight not normally available with the top-down governance and compliance methods of traditional enterprise data. And the user-provided tagging is very different to the rigid and controlled hierarchical taxonomies, structures and syntax that typically have been the basis of enterprise data approaches. And so on ... (I'll follow up on some of these separately).

So Web 2.0 will undoubtedly introduce new technologies like RSS, Wikis, REST, Blogs, AJAX etc into enterprise usage. But perhaps more interesting than the new technologies is the potential influences it will have on Enterprise Systems design and the way Enterprise Data Management will adapt.

For example:-

Web 2.0 EDM Influence	Challenged EDM Characteristic
Intellectual Commons	Not just Elite Experts
Emergence	Not just Upfront Grand Design
Dynamic Metadata	As well as Fixed Syntax
Tagging & Semantics	Instead of Just Hierarchies
Resources	Beyond Just Data
Links	As well as Replication
Others’ Resources as Your Platform	As well as Your Own

Many will recognise that there has been quite a lot of discussion about what Web 2.0 will mean to Enterprise IT generally (Andrew McAfee's Enterprise 2.0 threads are a fine example) but I havn't yet come across discussion on what it specifically may mean to Enterprise Data, which would seem to be one of the prime areas affected.

Technorati Tags: Enterprise IT Web 2.0 Web_2.0 web-20 Data Management Data Architecture Information Architecture Information Management

Architect Insight 2007 Event

Matt Deacon of Microsoft UK and IASA UK has just blogged about how he's tried to construct Microsoft's Architect Insight Conference at Celtic Manor in March this year so that it is as interactive and inclusive as possible, with discussions and working groups that are deliberately intended to ask questions and work through issues rather than presenting predetermined solutions. I'm looking forward to this dynamic, it should produce some interesting results, it might reduce the level of death-by-powerpoint, and maybe even keep some of the 'spin' in check.

What's particularly unusual about this event is the breadth of the agenda, with work-streams covering a broad set of areas such as 'enterprisey' strategy issues like the one I'm speaking on, through web, security, and infrastructure, as well as the software design issues (that you'd perhaps expect from an MS -organised event). It makes for an interesting mix of perspectives.

Technorati Tags: Enterprise IT Enterprise Architecture EA Software Architecture SOA Service Oriented Services Architecture Microsoft IASA

Open Group's EA London 2006

I was at the Open Group's Architecture Practitioners' Conference in central London last week. It was a good event, well organised by The Open Group and Architecting the Enterprise, with good facilities and well attended by mostly (as its title would suggested) EA practitioners. Rounding the sharp edge off the plenary sessions, Steve Redgrave closed the first day with a interesting talk on the complexities of the Olympics bid and organisation for 2012.

I'm pleased to say that unlike David Linthicum's and Todd Biske's recent observations from EAC in San Diego, there was a good amount of balanced attention to SOA as well as pure Enterprise Architecture. I would say that it did seem that most of the content was based firmly around either one or the other, but the organisers did a good job of mixing the agenda up to keep it balanced.

My slot was on how Enterprise Architects' roles need to evolve as SOA gains more traction in organisations. This wasn't to explore SOA as an architectural style, but rather to present how SOA had got many non-architects talking about architecture which is changing many non-EA methods and attitudes in Enterprise IT, and will have an important effect on the role and relationships that EAs should have within their organisations.

For example, the increase in the old need to get closer to individuals in the business units with change agendas, the need to accumulate more joint responsibility in project delivery and operations, and generally the imperative to have a hand in the ways that methods in other parts of IT are changing, rather than rising above it all. There is so much that needs involvement in fact that the need to develop ways to prioritise the use of architecture resources since good ones are so scarce is even more key. EA wouldn't want to spread itself too thinly after all.

I'm not sure of the organiser's plans for circulating the slides, but if anyone who was there wants a copy of the slides I presented, just drop me a mail using the address on my blogger profile page.

One of the other presentations on the first day that particularly caught my eye was David Robertson from IMD's presentation entitled EA: What to tell the Management Team. It drew from his work in the recent Harvard Business Press Book Enterprise Architecture as Strategy, and had some great material about engaging EA with the business and with projects, working towards making it pay for itself which was great to see. Recommended.

Technorati Tags: Enterprise IT EA Enterprise Architecture TOGAF The Open Group SOA Service Oriented Architecture Service-Oriented

Changes in the Role of the Enterprise CTO

I was talking with Ade McCormack of Auridian a few weeks ago on the changing nature of CIO and CTO roles that we were seeing in the organisations that we work with or talk to (mostly Western Europe-based).

Ade has incorporated some of his thoughts on the subject into his regular column in the FT last week, and it is definitely worth a look for anyone interested in IT leadership. If you didn't see it in print on Wednesday, then FT subscribers can get to it here, or it's on Auridian's site here.

Ade proposes that for organisations to be able to make use of IT effectively in developing their business model and their operating model, the CIO role needs to be far closer to, focused on, and more respected by the lines of business and the board. He describes that in order to free up the CIO to do that, you need to take away the operational side of the traditional CIO role. He proposes that the CTO role in organisations should change so it moves beyond the 'cleverest techie' that it tends to be now to apply its understanding of the technology to take operational accountabilities. He then proposes that this new repurposed role could then be supported by managers with the people skills and operational focus to run the IT department machine.

I like a lot of what Ade describes here, it has a lot of overlap with what I see. The CTO role as it exists in some organisations today can be a strange one. It is a term that has come from technology-centric companies such as Telcos, IT vendors etc who clearly need a technology visionary at the top of the organisation. But it has then been transposed into non-tech organisations, becoming a badge assumed by the people with the best technology expertise. But that doesn't seem appropriate for many. It can be difficult to justify the value of having a chief technical individual without accountabilities for realisation in non-tech-centric industries. Without accountabilities, CTOs' offices can become a strange kind of retained in-house IT analyst organisation, which isn't linked to value as the business would define it, and doesn't exactly help with business-IT alignment.

Of course outside of the US, organisations don't always use the terms CIO and CTO, indeed in the UK it's more common for the chief role to be IT director, however the same dynamics can still be seen. The value to decoupling operational and transformational focus, and the value of coupling technology strategy and realisation accountability both still apply.

Technorati Tags: Enterprise IT Business-IT Alignment IT Leadership IT Excellence Business-IT Engagement CIO CTO

DAMA Europe 2006 - Web 2.0 and Enterprise Data Management

I was at DAMA Europe 2006 in central London last week. I've been going for quite a few years now, and always find it thought-provoking. However there were some notable changes this year that were interesting.

The last couple of times I've spoken there it's been on more traditional Enterprise Data Architecture topics, which has been a good match - it is after all the largest independent Enterprise Data Management, Data Modelling, and Metadata Management event of the year. But this time I'd arranged with the organisers to do a bit of an off-the-wall topic drawing on Web 2.0 and asking what it might mean for Enterprise Data Management and Data Architectures.

In fact it seemed that there were similar messages starting to creep through into quite a few of the other presentations, which was very interesting. It seemed to represent a growing appreciation from some corners that the Enterprise Data Management community needs to think about managing information in ways beyond just the traditional consolidation, centralisation, replication and governance it has traditionally relied on.

I plan to put together some postings on the topics here, and having had several interesting conversations after the event with people that gave me some new ideas on how to structure this, I'd be interested to hear as well from others in the blogging community who have interests in this space.

Technorati Tags: DAMA2006 DAMA Enterprise IT Web 2.0 Web_2.0 web-20 Data Management Data Architecture Information Architecture Information Management