Hilarious. I have been using Ruby recently for all of my work with a not for profit organization and I love it. I think some of the irreverence is captured. I really like the way David characterized most of the languages. I just wish it could be about 5 times longer.
Thursday, November 29, 2007
Monday, November 19, 2007
Two Forces in Enterprise IT
A few weeks ago we had an executive summit at Gartner and I was quite pleased with our discussion with Anthony Bradley. His topic for the day focused around Enterprise 2.0 and the challenges and benefits that are being seen across industries. There were two themes that I have been pondering since that meeting.
The first issue is around security and the way corporations handle end user desktops. "Legacy Enterprises", with security teams leading the charge, have had a primary concern to prevent anything bad from happening. The natural outcome is to nearly prevent anything at all from happening. The companies that are thriving are the ones that are thinking about the situation in a different way. Instead of the negative, (to prevent bad things) they are looking from the positive context and are trying to encourage good things happening. This means instead of a locked down desktop, where IT spends enormous quantities removing software and turning things off in the operating systems, IT focuses on providing a place and a way for the business to do great things. If bad things do happen, they can be treated as precedents and, usually are bad employee behavior. Employees can be managed rather than forcing the issue with hardened systems and hand tied behind the users back.
The second issue hits right in the jaw of much of Enterprise Architecture. The premise of much of process driven Enterprise Architecture can include the Business Analysis, Business Process Modeling and subsequent refinements of model until you get to code and to working systems. These systems are typically "hard-coded" to business processes. Think a wizard implemented to handle stockroom ordering where each step is hard coded and tied in the models back to the business process. Anthony pointed out that much of what Enterprise 2.0 does is to recognize that this does not work in an environment where very little is static and stable. This leads to systems that meet the outdated requirements defined years before hand. If IT is to be relevant in the future of the corporation then we have to figure out how to stop doing this. The business knows their process. When IT models it we don't add value. What is needed is to have IT provide a container or an environment whereby the business can execute their business process. If those processes change we don't need to replace the application or the environment.
Needless to say I am quite intrigued with these thoughts (and many others that were presented on that day and since) and am curious to see how we can effect changes such as these in our corporate environment.
The first issue is around security and the way corporations handle end user desktops. "Legacy Enterprises", with security teams leading the charge, have had a primary concern to prevent anything bad from happening. The natural outcome is to nearly prevent anything at all from happening. The companies that are thriving are the ones that are thinking about the situation in a different way. Instead of the negative, (to prevent bad things) they are looking from the positive context and are trying to encourage good things happening. This means instead of a locked down desktop, where IT spends enormous quantities removing software and turning things off in the operating systems, IT focuses on providing a place and a way for the business to do great things. If bad things do happen, they can be treated as precedents and, usually are bad employee behavior. Employees can be managed rather than forcing the issue with hardened systems and hand tied behind the users back.
The second issue hits right in the jaw of much of Enterprise Architecture. The premise of much of process driven Enterprise Architecture can include the Business Analysis, Business Process Modeling and subsequent refinements of model until you get to code and to working systems. These systems are typically "hard-coded" to business processes. Think a wizard implemented to handle stockroom ordering where each step is hard coded and tied in the models back to the business process. Anthony pointed out that much of what Enterprise 2.0 does is to recognize that this does not work in an environment where very little is static and stable. This leads to systems that meet the outdated requirements defined years before hand. If IT is to be relevant in the future of the corporation then we have to figure out how to stop doing this. The business knows their process. When IT models it we don't add value. What is needed is to have IT provide a container or an environment whereby the business can execute their business process. If those processes change we don't need to replace the application or the environment.
Needless to say I am quite intrigued with these thoughts (and many others that were presented on that day and since) and am curious to see how we can effect changes such as these in our corporate environment.
My sister the wonderful geek
I had a lovely surprise this evening, when I saw my sister profiled at linux.com. This story can be seen here. She is the CEO of ZaReason which sells Ubuntu systems for great prices.
I was quite chuffed (pleased) with the story and what she is doing. Having a cool sister completely rocks. I remember a lifetime ago on the play ground we would say "my Dad can beat up your Dad". Now I can go to a dinner party and say "my Sister is smarter than your Sister."
I was quite chuffed (pleased) with the story and what she is doing. Having a cool sister completely rocks. I remember a lifetime ago on the play ground we would say "my Dad can beat up your Dad". Now I can go to a dinner party and say "my Sister is smarter than your Sister."
Thursday, November 15, 2007
Enterprise Architecture Stories - Nov 14, 07
A friend of mine at a large fortune 500 company is part of a global Enterprise Architecture governance board where the group recently decided what to do with LAMP as far as internal platform support. It became apparent, days later, that one of the leads of the community and all of the top tier consultants that support that person didn't know that PHP and LAMP are "related issues".
I asked my friend how a governing body can rule on something whose acronym is a mystery. My friend shrugged and said "meh". You can't make this stuff up.
I asked my friend how a governing body can rule on something whose acronym is a mystery. My friend shrugged and said "meh". You can't make this stuff up.
Subscribe to:
Posts (Atom)