Every once in a while I'm painfully reminded of the old admonition to be careful of what you wish for.
I recenly pointed out to a CIO that they had no Enterprise Architecture plan and that they really needed to develop one. He agreed and assigned me to create one.
Dang. Now I'm screwed.
I really hate the concept of Enterprise Architecture. The idea that you can create a document that describes EVERYTHING and yet can still be specific enough to mean anything is a stretch for me.
The vast majority of EA projects that I've worked on eventually devolved into a navel gazing, mom and apple pie, we all love each other kind of discussion. White papers that talk about what "should" happen don't really help drive change in an organization.
I really prefer a structured planning process that lets the organization adapt to change and implement new systems quickly. In my mind, it's about process and discipline, not about the one magic document that describes EVERYTHING.
So, if you will excuse me, I have a CIO that I have to talk down off the cliff....
Wish me luck.
Tuesday, November 18, 2008
Sunday, October 26, 2008
What vs. Why
As architect, I'm constantly asking why. Why do we need this system? Why is that feature important? Interestingly, when I work with a new client, the why of things is normally not included in the documentation or project artifacts.
What folks don't seem to understand is that project documentation serves two primary functions. One, to document what has been done and two, to help educate new team members on WHY things have been done.
Over the years, I have learned that there are really no right choices. Everything is a tradeoff. When a client asks, "is this the right design?" Or "is this the best practice?" I always cringe a bit inside. In reality, there are tons of bad designs and bad choices you can make but there isn't one single right answer.
So, focus on the why when considering a new design. The why will inevitably lead to the what and then to the how.
What folks don't seem to understand is that project documentation serves two primary functions. One, to document what has been done and two, to help educate new team members on WHY things have been done.
Over the years, I have learned that there are really no right choices. Everything is a tradeoff. When a client asks, "is this the right design?" Or "is this the best practice?" I always cringe a bit inside. In reality, there are tons of bad designs and bad choices you can make but there isn't one single right answer.
So, focus on the why when considering a new design. The why will inevitably lead to the what and then to the how.
Friday, October 24, 2008
How does IT Create Value?
I had a very interesting conversation today with a colleague from the operations side of the house. I was pontificating (as I'm wont to do) about IT's value proposition and talking about how IT needs to change to add value to the organization.
My operational colleague had a very intersesting perspective. His statement was that his department provided a "valuable service" to the organization every day. Whenever something breaks and they fix it, that's "value" in his mind.
My approach is somewhat different. I feel that the value proposition of any product tends to degrade over time. In the case of IT, we are always comparing ourselves against a commodity product and must constantly strive to exceed the value proposition of the steady state. In the end, I feel that IT organizations that don't innovate are bound to be outsourced.
Think of it this way:
IT costs are constantly rising. There's a "tax" that we all pay to have nifty laptops, e-mail and all the other fun things we consider normal these days. The tide of technology in our lives continues to rise. My three year old has more access to technology than NASA had when they launched the original Apollo missions. If my CEO has less advanced technology than his twelve year old, that's a problem. "Normal" today is very different than it was ten years ago. So far, this trend which is yet another byproduct of Moore's Law, shows no signs of slowing.
So, you have this treadmill that continues to run. You can run pretty quick on the treadmill and not get anywhere. Or, you can simply stop running and get left behind. That strategy works fine for a year or two, but eventually, you find yourself so far behind the market that you need to do a massive forklift upgrade. That's pretty painful on the IT team and the users. I don't recommend that approach. So the real question is how to you keep your IT department agile enough to stay ahead of the game and take the constant upgrade runaround as routine? This is really the minimum an IT department must do.
Back to my friend's beliefs. According to him, this action of keeping up with the tide is adding value to the organization. I don't really agree. If you simply keep pace, all that means is that your avoiding LOOSING GROUND. You're not really adding value. The real question that most IT organizations never ask is, how do we make the business better? How do we compete more effectively? How do we increase the top line or reduce the bottom line?
I firmly believe that we only add value when we CHANGE the business in some significant way. This means that we only add value when we inject change into the business. Therefore, change becomes the gating factor in our ability to create value. If we cannot inject change, we cannot create value. If our ability to inject change is limited, so is our ability to create value.
So what?
Well, it means that in order to be a good architect, you must become a change agent. You need to hone your ability to introduce change into the organization and understand how to deliver new systems and technologies with the minimum amount of disruption to the organization.
It also means that you need to understand the business that you find yourself in. This is what folks mean when they say that the architect needs to balance technical and business accumen. By understanding your internal and external customers, you have a better ability to proactively make changes that make the business better in new and unexpected ways.
My operational colleague had a very intersesting perspective. His statement was that his department provided a "valuable service" to the organization every day. Whenever something breaks and they fix it, that's "value" in his mind.
My approach is somewhat different. I feel that the value proposition of any product tends to degrade over time. In the case of IT, we are always comparing ourselves against a commodity product and must constantly strive to exceed the value proposition of the steady state. In the end, I feel that IT organizations that don't innovate are bound to be outsourced.
Think of it this way:
IT costs are constantly rising. There's a "tax" that we all pay to have nifty laptops, e-mail and all the other fun things we consider normal these days. The tide of technology in our lives continues to rise. My three year old has more access to technology than NASA had when they launched the original Apollo missions. If my CEO has less advanced technology than his twelve year old, that's a problem. "Normal" today is very different than it was ten years ago. So far, this trend which is yet another byproduct of Moore's Law, shows no signs of slowing.
So, you have this treadmill that continues to run. You can run pretty quick on the treadmill and not get anywhere. Or, you can simply stop running and get left behind. That strategy works fine for a year or two, but eventually, you find yourself so far behind the market that you need to do a massive forklift upgrade. That's pretty painful on the IT team and the users. I don't recommend that approach. So the real question is how to you keep your IT department agile enough to stay ahead of the game and take the constant upgrade runaround as routine? This is really the minimum an IT department must do.
Back to my friend's beliefs. According to him, this action of keeping up with the tide is adding value to the organization. I don't really agree. If you simply keep pace, all that means is that your avoiding LOOSING GROUND. You're not really adding value. The real question that most IT organizations never ask is, how do we make the business better? How do we compete more effectively? How do we increase the top line or reduce the bottom line?
I firmly believe that we only add value when we CHANGE the business in some significant way. This means that we only add value when we inject change into the business. Therefore, change becomes the gating factor in our ability to create value. If we cannot inject change, we cannot create value. If our ability to inject change is limited, so is our ability to create value.
So what?
Well, it means that in order to be a good architect, you must become a change agent. You need to hone your ability to introduce change into the organization and understand how to deliver new systems and technologies with the minimum amount of disruption to the organization.
It also means that you need to understand the business that you find yourself in. This is what folks mean when they say that the architect needs to balance technical and business accumen. By understanding your internal and external customers, you have a better ability to proactively make changes that make the business better in new and unexpected ways.
Subscribe to:
Posts (Atom)