Technology Architecture without sound Business and Service Architecture?
One of my clients asked me a pretty common question this week:
"Is it possible to develop a Technology Standards Profile (Technical Reference Model
since we're in the FEA
space) without working on the Service Component Profile?"I will also add the question of whether you can do this without the Business Architecture
His goal is a valid one: his organization has many disparate divisions and teams building IT systems and he wants a list of technologies that should be used to prevent using everything under the sun. His constraint is that they do not have the performance, business and service component architecture built out and he wants this concrete set of technical standards soon, rather than once the entire enterprise architecture is complete.
Of course, this is possible to survey the organization and create a list of all the technologies used. But in order to develop a set of technology standards for developing new systems, you really have to know which technologies stay, which ones go and (more importantly) what new technologies need to be added. The value of this analysis increases as you know what business drivers are determining what services will need to be developed. This will drive your technology.
In order to combat the pushback of "Don't tell me I can't use Java/Microsoft/Mainframes/whatever", you need a solid business case supporting the technology standards profile. Inevitably, if you don't have the solid grounding and line of sight through the entire architecture to justify technology standards you will start out with grumblings and skunk works trying to prove why their technology is best and should supplant the status quo (which sometimes is successful, but not always).
So the answer to my client's question is a difficult one for him: You're going to need an architecture that addresses the business, performance model and service/applications in order to reach your final goal of a technology standards profile. This means he'll need more resources and a tougher sell to his management, but it seems like at least 20% of enterprise architecture is justifying the benefits.