Tuesday, March 07, 2006
Thoughts on Process and Expectations
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.
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.
Links to this post: