I'm an happy Apple Mac user since one year now. I have never used a Mac before one year ago, when I decided to make the quantum leap, also because most of my Alfresco colleagues run a Mac and I have been always curious to try it. Before my idea was that Macs were cool but too much of a closed platform, now I think Macs are just the best way to have my work done. I do not want to judge some Apple's very restrictive policies here, everybody has a different opinion (I think the idea of forcing Objective-C on the iPhone is moving millions of Java developers toward Google Android, for example).
I had my MacBook Pro stolen few months ago but I also have an older PC-compatible laptop as a backup: after two days using it I felt the urgency to run to the very first Apple store to buy a new Mac. Back home, I opened the box, switch on it and after a few seconds it was able to recognize there is a NAS with Time-Machine backups: it offered me to restore the last backup and, after few hours, it was like my previous Mac was never stolen, as every piece of software was in its place, even the same desktop wallpaper and icons.
I never have to run anti-virus software, I never have to run any disk defragmentation or registry maintenance. I do not waste time in maintenance of hardware drivers: Apple design both hardware and software to work together, so that the user experience is always the smoothest. I'm also an happy user of Ubuntu Linux, which in my opinion is by far the best desktop Linux distribution. Ubuntu also runs daily in my Mac through a VirtualBox image, when I have to run some Linux software for my work. Despite the fact Ubuntu software is (almost) as easy as a Mac to install, configure and run, the fact is that Canonical - the company behind Ubuntu - is a software firm only, so they have to run their beautiful O.S. on a multitude of different hardware devices and software device drivers. This is the same problem Windows has. Each computer comes with different internal devices (motherboard, CPU, hard disk, network cards, Wifi cards, graphic card, ....), so there always a combination of hardware devices and software drivers which could cause a compatibility issue. It is always a race for Canonical, Microsoft and the others to prove their software on a plethora of hardware and sometimes broken drivers. So, when we put the blame on Microsoft in cases when Windows can be occasionally unstable, actually we should blame the real source, which usually is some sub-component of our PC and quite always a buggy software driver, which is out of control of Microsoft and others.
Of course, the above was especially true in the early days of personal computing, when enthusiasts like me were used to assemble their PC by hand. Now, if you buy especially a laptop from, say, Dell, HP, IBM, etc... you can be pretty sure all components are pre-tested, so everything will (almost) work just fine. However, nobody designs and produces beautiful hardware and client software like Apple does so, despite all competitors' efforts, my position is that the overall Apple user experience is still by far superior, exactly because every single component, together with communication, is designed with integration and user's experience in mind. It is interaction design at its best.
This positive and viable integration, by contrast, is very hard to be experienced when moving from consumer computing to Enterprise systems nowadays. Let's be honest: distributed enterprise systems are a total mess of hardware and software combinations. The level of incompatibility that we could have in a single consumer devices is multiplied by a magnitude factor. The major problems with Enterprise systems implemented, for example, in JEE or .NET, are due to inter-application and external systems integration issues. The applicative layer usually runs into different application servers, which runs over different operating systems and usually must connect to different relational databases, external information systems (ERP, CRM, ECM, etc....) and messaging systems. There is an explosive combinatorial matrix of configurations in need for testing and QA. At the end each customer needs to run on the existing infrastructure with few variations, so most of the time spent maintaining enterprise applications is actually spent trying to force a software into a specific and unique infrastructure: pitfalls are everywhere. Support centers spend most of their time just running after specific software + hardware configuration issues. No wonder if today some crucial business processes are still running into very old but well HW + SW integrated mainframes.
The positive Apple's integration model should work also for enterprise-class solutions. In my mind Sun Microsystems was one of the companies going closer to applying the Apple's consumer integrated design model to the enterprise world. Sun designed both hardware and software (Solaris O.S., Java, etc were tuned to specific Sun's servers and components). Buying a Sun server was usually a positive integrated experience, running Oracle on Sun servers was a rock-solid decision. The main problem, in my humble opinion, is that Sun was not ready or not willing to go the extra mile: moving the software stack up to applicative layer and moving their business out of the commoditized server business. I mean, Sun's management perceived they had to, as the late open-source initiatives testifies, but the company has never been structured to make this vital step forward executing the process in the right way (McNealy almost acknowledges this), so most of the ideas remained on paper or stuck without execution until Oracle's acquisition was the only way to save the company.
I think strong infrastructural integration is now not enough for a vendor to exit from commoditization trends and for a customer to solve integration's madeness. Some Cloud Computing initiatives are a clear step in the direction of moving the stack up from Infrastructure as a Service to actual Software as a Service. At the end, moving in the cloud the infrastructure only is not going to solve most of the applicative-level problems of moder enterprise solutions: if, for example, I run my software into Amazon EC2, I can solve many infrastructural provisioning problems in a row, but at the applicative layer my J2EE solution is still running into different O.S and application servers which need to be integrated and tested for compatibility and performances.
I guess, even if existing platforms are maybe too young and still immature to move all solutions there, the right direction for better isolating applications and application development from infrastructural problems will be to provide a complete, uniform applicative platform where most reliability and scalability problems are solved by model's definition. I think initiatives like the Google App Engine, VMWare's Cloud Application Framework, Salesforce Platfom are good examples of what could bring Apple's consumer-side positive experience into the enterprise applications ecosystem soon. Companies should eventually show some perspective, intelligence and courage and start experimenting as soon as possible.
Update (20 Jan 2011): Amazon has just announced the new AWS Elastic Beanstalk, which I think should be included in the above list of advanced PaaS solution. It looks much like GAP and at first sight Amazon's new platform shows an interesting degree of flexibility for developers. First released version is for Java.
Showing posts with label business. Show all posts
Showing posts with label business. Show all posts
Sunday, January 16, 2011
Sunday, October 19, 2008
When all are responsible, nobody is
Democracy doesn't fit well with software development, committees don't work for software development. Individual accountability works. Ask few good individuals for commitment and give them the power to act.
I'm trying to recall what the context usually is when things go wrong and what are the conditions when a project succeed. If I look back to my experience most of the successful software development projects I've been involved succeeded exactly when the decision chain was very short and decision taken promptly, especially the unpopular ones.
I think it was Fred Allen who said, "A committee is a group of men who individually can do nothing, but as a group decide that nothing can be done."
This is known also as a variant of the bystander effect. "The bystander effect (also known as bystander apathy, Genovese syndrome, diffused responsibility or bystander intervention) is a psychological phenomenon in which someone is less likely to intervene in an emergency situation when other people are present and able to help than when he or she is alone."
Really big distributed projects, say Linux and the Python language, have clear leadership expressed by few or even one person. Linux has Linus, Python has Guido. Are really our projects any bigger or more complex?
Now integration is organizationally harder than application development because integration is cross-department and under control of different ownership domains. If you leave the execution control to a committee than you can be pretty sure it is not going to deliver: distributed responsibility means almost no responsibility.
"A good plan violently executed now is better than a perfect plan executed next week."
- George S. Patton
If the team is big the Scrum agile project management process is something which could help splitting the team into smaller teams, each one with a local leader who reports to the top team leader (or top Scrum Master). The team leaders (local and top) are responsible to deliver the solution, the Time & Resource Manager is in charge to check time and budget, while the QA Manager is responsible to provide testing and validation. That's it.
If you think you can deliver any SOA or EAI project by creating a committee made of members of all IT department involved in the integration effort then you are doomed, you'll end into analysis-paralisys very soon because everybody want to say something. The next common mistake is adding developers to a late project: as Tom DeMarco taught, adding manpower to a late project actually makes it later.
“Craziness is doing the same thing and expecting a different result.”
- Tom DeMarco
We are convinced that software development management is hard, but too many times I'm experiencing self-handicapping management, when consultants or end customers are scared of taking any decision and just start blaming the tools they are using and start opening support incident without relying on what, if they, know. Then a two-months integration flow takes three years and twenty times the estimated budget.
If you have a problem, fix it now. When a better solution comes, refactor to integrate it to your fix.
"Anticipate the difficult by managing the easy."
- Lao Tzu
I'm trying to recall what the context usually is when things go wrong and what are the conditions when a project succeed. If I look back to my experience most of the successful software development projects I've been involved succeeded exactly when the decision chain was very short and decision taken promptly, especially the unpopular ones.
I think it was Fred Allen who said, "A committee is a group of men who individually can do nothing, but as a group decide that nothing can be done."
This is known also as a variant of the bystander effect. "The bystander effect (also known as bystander apathy, Genovese syndrome, diffused responsibility or bystander intervention) is a psychological phenomenon in which someone is less likely to intervene in an emergency situation when other people are present and able to help than when he or she is alone."
Really big distributed projects, say Linux and the Python language, have clear leadership expressed by few or even one person. Linux has Linus, Python has Guido. Are really our projects any bigger or more complex?
Now integration is organizationally harder than application development because integration is cross-department and under control of different ownership domains. If you leave the execution control to a committee than you can be pretty sure it is not going to deliver: distributed responsibility means almost no responsibility.
"A good plan violently executed now is better than a perfect plan executed next week."
- George S. Patton
If the team is big the Scrum agile project management process is something which could help splitting the team into smaller teams, each one with a local leader who reports to the top team leader (or top Scrum Master). The team leaders (local and top) are responsible to deliver the solution, the Time & Resource Manager is in charge to check time and budget, while the QA Manager is responsible to provide testing and validation. That's it.
If you think you can deliver any SOA or EAI project by creating a committee made of members of all IT department involved in the integration effort then you are doomed, you'll end into analysis-paralisys very soon because everybody want to say something. The next common mistake is adding developers to a late project: as Tom DeMarco taught, adding manpower to a late project actually makes it later.
“Craziness is doing the same thing and expecting a different result.”
- Tom DeMarco
We are convinced that software development management is hard, but too many times I'm experiencing self-handicapping management, when consultants or end customers are scared of taking any decision and just start blaming the tools they are using and start opening support incident without relying on what, if they, know. Then a two-months integration flow takes three years and twenty times the estimated budget.
If you have a problem, fix it now. When a better solution comes, refactor to integrate it to your fix.
"Anticipate the difficult by managing the easy."
- Lao Tzu
Saturday, January 6, 2007
Books: Enterprise SOA Adoption Strategies
Steve Jones, currently a CTO at Capgemini for SOA strategies, wrote this very interesting little book that fills a gap in the IT literature. The term SOA, which stands for Service Oriented Architecture, is a bit of an overused buzzword these days. SOA has to do much more with the business side of an enterprise than with the technological one, while most books focus their attention too much on technical aspects. The target of a SOA strategy, as Steve's book explain very well, is to "deliver IT to the business". This should sound very obvious, shouldn't it? In my experience many technology departments were nowadays being transformed into playgrounds for software programmers and mediocre IT managers instead. A SOA strategy must reinstate IT into its necessary form within the enterprise, which is to be business-driven.
Steve's book explain very well an analysis approach to model a SOA starting from main business functions, down to a decomposition to technical services. The key to a Service Oriented Architecture? As he wrote: "It's the Service, Stupid!". So the second important concept you will understand reading his book is another very often missed point:
SOA must be business-driven and not technology-driven
Steve's book explain very well an analysis approach to model a SOA starting from main business functions, down to a decomposition to technical services. The key to a Service Oriented Architecture? As he wrote: "It's the Service, Stupid!". So the second important concept you will understand reading his book is another very often missed point:
Subscribe to:
Posts (Atom)