Prepend
2007-09-21
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.
"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.
Labels: EA
¶ 7:38 PM 0 comments
2007-09-05
Enterprise Architecture is IT speak
I was recently at the PHIN 2007 conference facilitating a stakeholder group on collaboration and witnessed the following conversation with state and local public health partners:
It's interesting to witness this for two reasons:
1) They've obviously encountered EA before and it left a bad taste in their mouth. This seems fairly common as a large portion of my engagements involve explaining how we aren't like those other EA guys who wasted their time and money.
2) It is an artificial term that reeks of IT speak.
As much as EA claims to be about the business and how business should drive EA, the EA organization is under the CIO/CTO in 9 out of 10 organizations (at least in the federal environment it is mandated by Clinger-Cohen). We constantly use technical jargon even when we don't think we are doing so.
Another recent anecdote I had when talking with a business steward about what the difference between a data repository and a data warehouse is:
Now, granted, this is to explain the arbitrary definition of data warehouse/repository that the technical group had developed. But I was trying to clear up this confusion. The business steward is a brilliant person with a PhD and everything but she said
If EA really wants to engage with the business side of the organization, it needs to stop using geeky terms like "architecture", "enterprise", "service" (in an SOAy sense), etc etc.
A final example: In the FEA Practice Guide it says "Architect, Invest, Implement".
What other practice verbs nouns as much as IT? I mean seriously, if you buy a house does your architect say "I'm going to go architect up your blueprint sir."
Anyway, the point of this post is that EA should strive to remove the IT vocabulary and talk like the rest of the business people that EA strives to be.
Person A: We would benefit if we had a common strategy defined that we could follow.
Person B: Yes, we could define our processes so we could compare what we have in common and collaboration on systems.
A: Then we could create a plan for how to align our IT investment with business drivers (seriously, they said exactly this)
Person C: That's called enterprise architecture, you're talking about enterprise architecture.
B: No, don't say that word.
A: Yeah, what does that even mean? We looked up "enterprise" in the dictionary and it means a risk taking endeavor.
It's interesting to witness this for two reasons:
1) They've obviously encountered EA before and it left a bad taste in their mouth. This seems fairly common as a large portion of my engagements involve explaining how we aren't like those other EA guys who wasted their time and money.
2) It is an artificial term that reeks of IT speak.
As much as EA claims to be about the business and how business should drive EA, the EA organization is under the CIO/CTO in 9 out of 10 organizations (at least in the federal environment it is mandated by Clinger-Cohen). We constantly use technical jargon even when we don't think we are doing so.
Another recent anecdote I had when talking with a business steward about what the difference between a data repository and a data warehouse is:
"The data repository contains the raw data received from parters. The data is then processed with business rules applied and loaded into the data warehouse. The data warehouse has analysis and structure for the aggregate data."
Now, granted, this is to explain the arbitrary definition of data warehouse/repository that the technical group had developed. But I was trying to clear up this confusion. The business steward is a brilliant person with a PhD and everything but she said
"Sorry, I don't know what you just said."
If EA really wants to engage with the business side of the organization, it needs to stop using geeky terms like "architecture", "enterprise", "service" (in an SOAy sense), etc etc.
A final example: In the FEA Practice Guide it says "Architect, Invest, Implement".
What other practice verbs nouns as much as IT? I mean seriously, if you buy a house does your architect say "I'm going to go architect up your blueprint sir."
Anyway, the point of this post is that EA should strive to remove the IT vocabulary and talk like the rest of the business people that EA strives to be.
Labels: EA
¶ 8:36 PM 0 comments
