Enterprise Architecture

I wanted to add my commentary to Scott Mark's excellent post about Agile in enterprises. I have participated and managed a few agile projects in the last few years and am sold on the concepts (as I am other methodologies) but retain my agnosticism as I strongly prefer to use different processes and methodologies as the situation dicates, and not dogmatically (which usually invites trouble in most cases).

The overall problems appear to me as attempts to strike a balance between results, process, and the expectations of users & the business. This balance is so tough to strike that few will truly succeed 100% in satisfiying all stakeholders, particularly on large projects.

Here are a few examples of perceptions/statements/mantras we all have been exposed to whether on-the-job or in publications and blogs:

• The systems and applications IT develops cost too much and take to long to implement.
• It costs too much to maintain operational IT systems (the 'keeping the lights on' part of the budget that is 70-80% of most IT expense).
  
• It costs too much because of, as Scott aptly states "waste...being ceremonial or overhead activities that do not directly add value."
• We can cut IT costs with an enterprise architecture (and indirectly, a SOA) that unifies and integrates applications and infrastructure
• We develop one-offs and small-project apps that the business requires quickly but are difficult to maintain and support, don't interoperate with anything else we have in production or on the whiteboard, and have some development activities that are repetitive (particularly data and database-related) as we need to re-model or re-engineer the data access and movement/integration because of 'unique' business requirements.
• We can implement and deploy faster if we continue using [fill in older technology here] rather than web services (and indirectly, a SOA), because that is what we know how to do without additional training or outside help.
• We can service-enable anything faster and cheaper using REST rather than WS-* because the latter is cumbersome, too complex, and more difficult to implement.

I offer these as examples of statements and aspirations that compete with each other negatively in terms of overall business-technology approach and balance. The conundrum here is if we over-specify, over-document, or over-process (and that depends largely on which perception of 'over-' is being utilized), we take too long and are too spendy for the value received by the business. If we cut out too much, we run the risk of deploying systems marginally supportable that will need to be refactored (or in extreme cases, ditched and redone) because the inevitable changes to the system cost more than anticipated in time and money. This also lowers the value received.

What further muddies the water here is SOA itself. We're finding out that comprehensive SOAs are not built quickly and cheaply, and definitely not quick or inexpensive enough to satisfy urgent business needs. Well-built SOAs will pay back much more than they cost - eventually, and not fast enough to satisfy some parts of the business.

Finally, we get to the question of "value" of any process, activity, or sets of these. The question behind this is 'value to whom?' Business agility is one thing, IT agility is another, and overall costs to develop, deploy, and support are yet another. What kind of balance are we looking for here, and can we achieve some sort of consensus on this with the stakeholders?

I realize I'm asking a few more questions in this post than I'm answering, and much more thought and dialog is required. Scott and Cote' have begun a very interesting topic...much more to follow.


enterprise architecture