Thursday, June 15, 2006
Can Enterprise Architects learn from the folks over at 37Signals?
The folks over at 37 Signals talks about the notion of temporary software while us enterprise architect types tend to refer to the monstrous extremely complicated stuff we oversee as assets. What if we asked ourselves, how do we make our software disposable?
One of the bigger evils that Service Oriented Architectures brings with it is the mindset of reuse. Some things simply shouldn't be reused. If Enterprise Architects were to attend conferences sponsored by industry analyst firms such as the 451 Group, you would hear attendees such as Loglogic talking about the importance of having an exit.
The dot-com mindset never really made it to corporate America or we are just catching up to it. Imagine if we started asking ourselves how difficult it would be to take software out several years from now and shoot it. Of course this would require asking ourselves deeper questions regarding integration complexity, the huge cost of maintenance and even to think about the subsequent deluge of monotone meetings.
If I were to advocate within an enterprise context< that enterprises start paying deeper attention to web 2.0 companies, I would be embraced by those whom already crossed the chasm while being eschewed by those who haven't. Is it practical to think any large IT shop would adapt their processes and more importantly their culture to make their software more disposable?
I can see lots of enterprise architects asking themselves how does Ruby on Rails integrate with their Enterprise Service Bus but not asking themselves whether they needed an Enterprise Service Bus in the first place? Ruby on Rails demands simplcity, something that is good for the enterprise yet will also be an impediment to its rapid adoption. Maybe Ruby on Rails and the community is more service-oriented than we give them credit for, and all we need is simply a better definition of SOA...
| | View blog reactionsOne of the bigger evils that Service Oriented Architectures brings with it is the mindset of reuse. Some things simply shouldn't be reused. If Enterprise Architects were to attend conferences sponsored by industry analyst firms such as the 451 Group, you would hear attendees such as Loglogic talking about the importance of having an exit.
The dot-com mindset never really made it to corporate America or we are just catching up to it. Imagine if we started asking ourselves how difficult it would be to take software out several years from now and shoot it. Of course this would require asking ourselves deeper questions regarding integration complexity, the huge cost of maintenance and even to think about the subsequent deluge of monotone meetings.
If I were to advocate within an enterprise context< that enterprises start paying deeper attention to web 2.0 companies, I would be embraced by those whom already crossed the chasm while being eschewed by those who haven't. Is it practical to think any large IT shop would adapt their processes and more importantly their culture to make their software more disposable?
I can see lots of enterprise architects asking themselves how does Ruby on Rails integrate with their Enterprise Service Bus but not asking themselves whether they needed an Enterprise Service Bus in the first place? Ruby on Rails demands simplcity, something that is good for the enterprise yet will also be an impediment to its rapid adoption. Maybe Ruby on Rails and the community is more service-oriented than we give them credit for, and all we need is simply a better definition of SOA...
