Ray Ozzie is leaving Microsoft.
After it was announced that he was leaving, he published a memo on his blog. The memo, titled Dawn of a New Day, is an excellent read. In fact, I’m in awe of people who can write like Mr. Ozzie can.
While reading through the memo (yes…I read the whole thing)…i hit upon this nugget:
Complexity kills. Complexity sucks the life out of users, developers and IT. Complexity makes products difficult to plan, build, test and use. Complexity introduces security challenges. Complexity causes administrator frustration.
Powerful stuff.
I think those five sentences fully explain the state of IT today. And…they thoroughly explain the basis for the hatred (or at least dislike) that most people within organizations have toward IT.
We’ve built a world within IT that enjoys complexity. We’ve built a group that thrives on complexity. But…that complexity is killing organizations.
That complexity is why Shadow IT exists. That complexity is why many groups within modern day organizations are driving hard toward a time when they own / manage their own technology platforms. Scott Brinker is making a very good argument for Why Marketing Should Run its own Technology. Mitch Joel is pointing at Technology is being a major part of the Agency of the Future…but I don’t see a CIO in that agency (and that’s not a bad thing).
Complexity does kill….and is killing the IT group.
What can we do to move towards a more simplistic approach to IT?
The answer to that question will determine The Future of IT.
20 responses to “Complexity & IT”
Eric,
Can you clarify your definition of “complexity in IT”? Is this complexity from an end user interaction perspective or is it complexity inherent in the IT systems IT delivers to the end user?
Sure.
Its both 🙂
Complexity in the end user interaction with IT systems and IT in general. Complexity in how IT projects are undertaken and managed.
Also…the complexity in how IT system are built and managed. While these systems will always be complex, we (IT leaders / managers) have got to do a better job of staying as close to the KISS approach as possible. I know many IT professionals who architect and design in complexity just for complexity’s sake.
I should have known the obvious answer to me question … 🙂
How do you assess an ESB in SOA in terms of complexity in the complexity equation you are proposing?
Caveat: I’m not that knowledgeable in the area of SOA..but I know enough to be dangerous.
The ESB in an SOA environment is a perfect example….the enterprise service bus is leading us toward a more simplistic solution to the ‘gobbledeegook’ (that’s a technical term!) created when many web services are integrated. With the ESB, you’ve built in a standard communication ‘path’ between various web services, data repositories and outputs.
Long ago, we moved from simple ‘point A to point B’ IT systems…and that’s OK by me. What I’m trying to argue (and maybe not doing a great job at it) is that we shouldn’t over design and over build when we can help it. The complexities that we build into our IT systems will be noticed by the end user.
Ok … think I follow your thought process.
In order to deliver feature rich value to end users, I think IT systems may need to be complex in order to deliver that value. I think some people would argue that System A directly talking to System B is more simple than System A talking to ESB talking to System B. Yet, there is arguably a tipping point when the inter-meshing of communicating system complexity exceeds the base level complexity an ESB introduces.
Complexity & IT http://bit.ly/dBgHck #cio #It
RT @ericdbrown: Complexity & IT http://bit.ly/dBgHck #cio #It
Complexity & IT http://restwrx.com/d5RR8T via @EricDBrown
#baot Reading: Complexity & IT http://ht.ly/19GmdR
IT often embraces complexity, which may just be its undoing. RT @ericdbrown Complexity and IT http://bit.ly/dBgHck #cio #It
Hi Eric, can’t agree more. We’re immersed so deeply in this complex web of complex processes and methodologies without realizing that the last thing they contribute to is quality. I’ve attempted to address this issue in a number of articles on my blog, the last of which (see http://quantmleap.com/blog/2010/10/quote-of-the-day-more-on-too-much-process/) was one where I brought a quote from an address by Vivek Kundra (the person charged with the strategic direction of IT coordination across the entire federal U.S. government). And this is what he had to say: “The government has created a culture where process continues to trump outcomes”. Pretty powerful stuff.
Thanks Shim…great stuff.
Love your blog…I’ve added it to my feed reader. Thanks for stopping by!
RT @ericdbrown: Complexity & IT http://bit.ly/dBgHck #cio #It
Complexity & IT: Ray Ozzie is leaving Microsoft.
After it was announced that he was leaving, he published a memo o… http://bit.ly/aj6HQw
[…] with too much processes, I’ve come across a beautiful post by Eric D. Brown titled “Complexity & IT“. Eric has been diligent enough to read through a rather long memo published by Ray Ozzie […]
Shared: Complexity & IT http://bit.ly/a0bJc8
RT @projectshrink: Shared: Complexity & IT http://bit.ly/a0bJc8
@ericdbrown Complexity & IT: http://ow.ly/346ys | So true. Over engineering kills most functions & methodologies.
#pmot #PMP #BPM #IT
Hi Eric, you might wish to provide your perspective on a comment given by Patrick Richard in http://quantmleap.com/blog/2010/11/more-on-the-topic-of-complex-it-processes/ (where I’ve made a reference to your article above).
I wonder what your view on this issue is.
Cheers, Shim.
Thanks for the pointer Shim…I’ve left a comment for you and Patrick.