In my previous organisation every employee used to have a three letter acronym (TLA) made from employee first, middle and last name, instead of an employee number. There was an anecdote about it as well. The company's then chief, who is also called "Father of the Indian Software Industry" had actually ordered a four letter acronym (FLA). But the software that was used to generate those acronyms, produced a nasty one for the chief. (If you know his name, you can imagine what that four letter word would have been). So he ordered it to be changed to a three letter one. (BTW, Many happy returns of the day Mr. Kohli).
It appears to be going in reverse within IT. In IT, there were a lot of TLAs. ERP, SCM, CRM, EAI, BPM and SOA to name a few you may have come across. Of late however the trend is moving towards FLAs, what with SaaS, PaaS and so on. However the most enduring acronym which survived the test of time is neither a three letter one nor a four letter one. It is actually a five letter one - RDBMS.
The reason it has survived for this long, is because it is more than an acronym. It is a well thought out piece of technology backed by solid science. It is not just an acronym coined by sales and marketing guys nor an industry analyst. This technology has proven to be easily standardised, exetensible and serving the vast array of requirements some of which was not even envisaged when technology was initially developed.
Sadly same cannot be said of all the technologies you see around these days. Many of them are rehash of old ideas in new packaging. They rely on finding the right audience at right time to proliferate and thrive on inherent problems they carry to generate more revenues for their owners.
Enterprise architects need to possess the vision to see thru the marketing fluff and reach the bare bones of technologies they are going to employ. Analysts can help to an extent, but the generic analysis may not be completely applicable in your situation. You need to equip your 'Oracle' function with this capability.
These are my thoughts about various issues faced by an enterprise architect.
Here you will find thoughts related to enterprise architecture, TOGAF, SOA, BPM, MDA, MDD, Web 2.0 etc.
Friday, February 27, 2009
Friday, February 13, 2009
IBM in cloud.
I read about Nick Carr commenting on IBM putting their infrastructure software in Amazon EC2. He is comparing it with IBM's disastrous decision to leave IP rights of Microsoft-Dos with, well, MicroSoft. Is this recent decision really comparable?
In case of PC, in hind sight it appears that IBM had erroneously assumed that their micro-processor based PC was non commoditisable, whereas Microsoft correctly judged that anyone could assemble a PC using off-the-shelf microprocessors from Intel. So Microsoft retained IP on software which it could use to monopolise the commodity PC market.
So the question in this scenario is what is likely to be commoditised? Are EC2 services that unique that no-one else could replicate? What is the barrier to entry?
Certainly not technology. If my memory serves me right, IBM itself is big daddy of virtualisation and what it calls utility computing. It had developed first hypervisor called VM CP, which used to run on S/xxx mainframes. In recent times, I remember using IBM provided Linux image on a mainframe in 2001 to do some personal project (I was trying to do some code visualisation into model using open source tools on IBM provided Linux image.) IBM had provisioned that image in 24 hours.
So what is it? My guess is IBM is using EC2 to hook users onto its IP and then move them to a different Cloud (possibly its own). I think IBM is still not worked out the business model around its own cloud offering for SMB. Not a bad thing. It will surely standardise cloud computing space and make enterprise scale software stack available even to SMBs. It might hasten uptake of private cloud offerings too. So everyone will benefit. It would be interesting to see how this works out in next few years. I am definitely going to watch the progress.
In case of PC, in hind sight it appears that IBM had erroneously assumed that their micro-processor based PC was non commoditisable, whereas Microsoft correctly judged that anyone could assemble a PC using off-the-shelf microprocessors from Intel. So Microsoft retained IP on software which it could use to monopolise the commodity PC market.
So the question in this scenario is what is likely to be commoditised? Are EC2 services that unique that no-one else could replicate? What is the barrier to entry?
Certainly not technology. If my memory serves me right, IBM itself is big daddy of virtualisation and what it calls utility computing. It had developed first hypervisor called VM CP, which used to run on S/xxx mainframes. In recent times, I remember using IBM provided Linux image on a mainframe in 2001 to do some personal project (I was trying to do some code visualisation into model using open source tools on IBM provided Linux image.) IBM had provisioned that image in 24 hours.
So what is it? My guess is IBM is using EC2 to hook users onto its IP and then move them to a different Cloud (possibly its own). I think IBM is still not worked out the business model around its own cloud offering for SMB. Not a bad thing. It will surely standardise cloud computing space and make enterprise scale software stack available even to SMBs. It might hasten uptake of private cloud offerings too. So everyone will benefit. It would be interesting to see how this works out in next few years. I am definitely going to watch the progress.
Thursday, February 12, 2009
Darwin and enterprise architecture
Today is 200th birth anniversary one of the great thinkers of modern times. Darwin presented us with the theory of evolution, summed up as 'natural selection' or 'survival of the fittest'. We also know that applying Darwinism in all spheres (e.g. social sphere - a la Nietzsche/Hitler) is not a good idea. However thats what tends to happen when it comes to enterprise IT. The evolution of enterprise IT tends to follow, the evolution of enterprise itself. As enterprises evolve, different parts of its value chain become important and get more attention (consequently more resource allocation). This weird sort of natural selection leads to multiplicity of systems and infrastructure, which tend to overlap or in rare cases leave gaps.
Over a period of time, the architectural environment, may it be business, application or technology architecture gets contaminated. This leads to bloated cost base and starts affecting time to market for business change. Approaches such as portfolio rationalisation can restore order temporarily. But to retain some semblance of order all the time, a proper enterprise architecture function must oversee the enterprise IT.
However what I have seen happening in practice is that at best of times the enterprise architecture function gets tolerated at most, and given total short shrift during bad times (such as current times). Focus moves to doing change projects faster and cheaper. The old wisdom is however easily forgotten, in being penny wise on short term project costs and time lines, we ignore the pound foolishness of bloated cost base and compromised time to market for future changes. However I also tend to agree that business change cannot wait for the right architecture to be put in place first. Businesses normally have window of opportunity to cash in, and cash in they will - with, without or despite IT.
Thats where the concept of Enterprise IT Oracle comes in. The Enterprise IT Oracle will let IT predict the future as envisaged by business, and put the right architecture (with appropriate governance) in place even before the need arises. It kind of puts IT in an offside position (soccer/football term) so that when business wants to pass the ball, IT is ready to receive it and shoot it into the goal. It is my firm belief that without such 'Oracle' function, enterprise architecture functions in reactive mode will never be able to rise to occasions.
Over a period of time, the architectural environment, may it be business, application or technology architecture gets contaminated. This leads to bloated cost base and starts affecting time to market for business change. Approaches such as portfolio rationalisation can restore order temporarily. But to retain some semblance of order all the time, a proper enterprise architecture function must oversee the enterprise IT.
However what I have seen happening in practice is that at best of times the enterprise architecture function gets tolerated at most, and given total short shrift during bad times (such as current times). Focus moves to doing change projects faster and cheaper. The old wisdom is however easily forgotten, in being penny wise on short term project costs and time lines, we ignore the pound foolishness of bloated cost base and compromised time to market for future changes. However I also tend to agree that business change cannot wait for the right architecture to be put in place first. Businesses normally have window of opportunity to cash in, and cash in they will - with, without or despite IT.
Thats where the concept of Enterprise IT Oracle comes in. The Enterprise IT Oracle will let IT predict the future as envisaged by business, and put the right architecture (with appropriate governance) in place even before the need arises. It kind of puts IT in an offside position (soccer/football term) so that when business wants to pass the ball, IT is ready to receive it and shoot it into the goal. It is my firm belief that without such 'Oracle' function, enterprise architecture functions in reactive mode will never be able to rise to occasions.
Subscribe to:
Posts (Atom)
Friday, February 27, 2009
Of TLAs and FLAs
In my previous organisation every employee used to have a three letter acronym (TLA) made from employee first, middle and last name, instead of an employee number. There was an anecdote about it as well. The company's then chief, who is also called "Father of the Indian Software Industry" had actually ordered a four letter acronym (FLA). But the software that was used to generate those acronyms, produced a nasty one for the chief. (If you know his name, you can imagine what that four letter word would have been). So he ordered it to be changed to a three letter one. (BTW, Many happy returns of the day Mr. Kohli).
It appears to be going in reverse within IT. In IT, there were a lot of TLAs. ERP, SCM, CRM, EAI, BPM and SOA to name a few you may have come across. Of late however the trend is moving towards FLAs, what with SaaS, PaaS and so on. However the most enduring acronym which survived the test of time is neither a three letter one nor a four letter one. It is actually a five letter one - RDBMS.
The reason it has survived for this long, is because it is more than an acronym. It is a well thought out piece of technology backed by solid science. It is not just an acronym coined by sales and marketing guys nor an industry analyst. This technology has proven to be easily standardised, exetensible and serving the vast array of requirements some of which was not even envisaged when technology was initially developed.
Sadly same cannot be said of all the technologies you see around these days. Many of them are rehash of old ideas in new packaging. They rely on finding the right audience at right time to proliferate and thrive on inherent problems they carry to generate more revenues for their owners.
Enterprise architects need to possess the vision to see thru the marketing fluff and reach the bare bones of technologies they are going to employ. Analysts can help to an extent, but the generic analysis may not be completely applicable in your situation. You need to equip your 'Oracle' function with this capability.
It appears to be going in reverse within IT. In IT, there were a lot of TLAs. ERP, SCM, CRM, EAI, BPM and SOA to name a few you may have come across. Of late however the trend is moving towards FLAs, what with SaaS, PaaS and so on. However the most enduring acronym which survived the test of time is neither a three letter one nor a four letter one. It is actually a five letter one - RDBMS.
The reason it has survived for this long, is because it is more than an acronym. It is a well thought out piece of technology backed by solid science. It is not just an acronym coined by sales and marketing guys nor an industry analyst. This technology has proven to be easily standardised, exetensible and serving the vast array of requirements some of which was not even envisaged when technology was initially developed.
Sadly same cannot be said of all the technologies you see around these days. Many of them are rehash of old ideas in new packaging. They rely on finding the right audience at right time to proliferate and thrive on inherent problems they carry to generate more revenues for their owners.
Enterprise architects need to possess the vision to see thru the marketing fluff and reach the bare bones of technologies they are going to employ. Analysts can help to an extent, but the generic analysis may not be completely applicable in your situation. You need to equip your 'Oracle' function with this capability.
Friday, February 13, 2009
IBM in cloud.
I read about Nick Carr commenting on IBM putting their infrastructure software in Amazon EC2. He is comparing it with IBM's disastrous decision to leave IP rights of Microsoft-Dos with, well, MicroSoft. Is this recent decision really comparable?
In case of PC, in hind sight it appears that IBM had erroneously assumed that their micro-processor based PC was non commoditisable, whereas Microsoft correctly judged that anyone could assemble a PC using off-the-shelf microprocessors from Intel. So Microsoft retained IP on software which it could use to monopolise the commodity PC market.
So the question in this scenario is what is likely to be commoditised? Are EC2 services that unique that no-one else could replicate? What is the barrier to entry?
Certainly not technology. If my memory serves me right, IBM itself is big daddy of virtualisation and what it calls utility computing. It had developed first hypervisor called VM CP, which used to run on S/xxx mainframes. In recent times, I remember using IBM provided Linux image on a mainframe in 2001 to do some personal project (I was trying to do some code visualisation into model using open source tools on IBM provided Linux image.) IBM had provisioned that image in 24 hours.
So what is it? My guess is IBM is using EC2 to hook users onto its IP and then move them to a different Cloud (possibly its own). I think IBM is still not worked out the business model around its own cloud offering for SMB. Not a bad thing. It will surely standardise cloud computing space and make enterprise scale software stack available even to SMBs. It might hasten uptake of private cloud offerings too. So everyone will benefit. It would be interesting to see how this works out in next few years. I am definitely going to watch the progress.
In case of PC, in hind sight it appears that IBM had erroneously assumed that their micro-processor based PC was non commoditisable, whereas Microsoft correctly judged that anyone could assemble a PC using off-the-shelf microprocessors from Intel. So Microsoft retained IP on software which it could use to monopolise the commodity PC market.
So the question in this scenario is what is likely to be commoditised? Are EC2 services that unique that no-one else could replicate? What is the barrier to entry?
Certainly not technology. If my memory serves me right, IBM itself is big daddy of virtualisation and what it calls utility computing. It had developed first hypervisor called VM CP, which used to run on S/xxx mainframes. In recent times, I remember using IBM provided Linux image on a mainframe in 2001 to do some personal project (I was trying to do some code visualisation into model using open source tools on IBM provided Linux image.) IBM had provisioned that image in 24 hours.
So what is it? My guess is IBM is using EC2 to hook users onto its IP and then move them to a different Cloud (possibly its own). I think IBM is still not worked out the business model around its own cloud offering for SMB. Not a bad thing. It will surely standardise cloud computing space and make enterprise scale software stack available even to SMBs. It might hasten uptake of private cloud offerings too. So everyone will benefit. It would be interesting to see how this works out in next few years. I am definitely going to watch the progress.
Thursday, February 12, 2009
Darwin and enterprise architecture
Today is 200th birth anniversary one of the great thinkers of modern times. Darwin presented us with the theory of evolution, summed up as 'natural selection' or 'survival of the fittest'. We also know that applying Darwinism in all spheres (e.g. social sphere - a la Nietzsche/Hitler) is not a good idea. However thats what tends to happen when it comes to enterprise IT. The evolution of enterprise IT tends to follow, the evolution of enterprise itself. As enterprises evolve, different parts of its value chain become important and get more attention (consequently more resource allocation). This weird sort of natural selection leads to multiplicity of systems and infrastructure, which tend to overlap or in rare cases leave gaps.
Over a period of time, the architectural environment, may it be business, application or technology architecture gets contaminated. This leads to bloated cost base and starts affecting time to market for business change. Approaches such as portfolio rationalisation can restore order temporarily. But to retain some semblance of order all the time, a proper enterprise architecture function must oversee the enterprise IT.
However what I have seen happening in practice is that at best of times the enterprise architecture function gets tolerated at most, and given total short shrift during bad times (such as current times). Focus moves to doing change projects faster and cheaper. The old wisdom is however easily forgotten, in being penny wise on short term project costs and time lines, we ignore the pound foolishness of bloated cost base and compromised time to market for future changes. However I also tend to agree that business change cannot wait for the right architecture to be put in place first. Businesses normally have window of opportunity to cash in, and cash in they will - with, without or despite IT.
Thats where the concept of Enterprise IT Oracle comes in. The Enterprise IT Oracle will let IT predict the future as envisaged by business, and put the right architecture (with appropriate governance) in place even before the need arises. It kind of puts IT in an offside position (soccer/football term) so that when business wants to pass the ball, IT is ready to receive it and shoot it into the goal. It is my firm belief that without such 'Oracle' function, enterprise architecture functions in reactive mode will never be able to rise to occasions.
Over a period of time, the architectural environment, may it be business, application or technology architecture gets contaminated. This leads to bloated cost base and starts affecting time to market for business change. Approaches such as portfolio rationalisation can restore order temporarily. But to retain some semblance of order all the time, a proper enterprise architecture function must oversee the enterprise IT.
However what I have seen happening in practice is that at best of times the enterprise architecture function gets tolerated at most, and given total short shrift during bad times (such as current times). Focus moves to doing change projects faster and cheaper. The old wisdom is however easily forgotten, in being penny wise on short term project costs and time lines, we ignore the pound foolishness of bloated cost base and compromised time to market for future changes. However I also tend to agree that business change cannot wait for the right architecture to be put in place first. Businesses normally have window of opportunity to cash in, and cash in they will - with, without or despite IT.
Thats where the concept of Enterprise IT Oracle comes in. The Enterprise IT Oracle will let IT predict the future as envisaged by business, and put the right architecture (with appropriate governance) in place even before the need arises. It kind of puts IT in an offside position (soccer/football term) so that when business wants to pass the ball, IT is ready to receive it and shoot it into the goal. It is my firm belief that without such 'Oracle' function, enterprise architecture functions in reactive mode will never be able to rise to occasions.
Subscribe to:
Posts (Atom)