Fluid Architecture
For those of us who struggle with the continuous competing demands of business and are responsible for design and implementation of technology, there are some great points in this post about Fluid Architecture by Simeon Simeonov. If I were to mention one take-away it would be the 3 things Simeon mentions as the key to success for fluid architecture: good software architecture, continuous process improvement component and a cultural component.
I am glad that Wordpress, the powerful software which enables this blog, gets a well-deserved praise.
Simeon Simeonov at High Contrast.
Sometimes, trading speed and efficiency now for cost and effort later helps startups reach some form of initial scale which buys them either enough capital or time to fix things before the next stage of growth. Other times, the same repeated trade-off puts them farther and farther behind the 8-ball. Nowhere is this more visible then when a product (or site) has to go through a major re-architecture (re-platforming/redesign).
Have you heard about Amazon’s latest re-platforming project? No? Not surprisingly since Amazon hasn’t had one of those… Great products/sites can evolve and take on best-of-breed capabilities/ technologies in a way that’s almost transparent to their users. Amazon is a great example. The site is constantly being worked upon by lots of people. Wordpress is another great example, showing the power of the open-source community. Good products/sites can be re-architected or re-platformed with relatively benign levels of user disruption. MySpace is a good example. MySpace had to significantly evolve their initial architecture (a web site built on one ColdFusion server) to end up where they are now. Others, say, the first-generation Friendster and many e-commerce sites, make it painfully obvious to their customers that it’s taking them too long to evolve & improve. Some die in the process.
IA common pattern is that many successful technology companies have figured how to use what I like to call fluid architecture to manage the balance of trade-offs between the present and the future. Fluid architecture is not just about software. The core certainly is about good software architecture but there is also a continuous improvement process component and a cultural component. The cultural element has to do with two things: (a) a mindset of ongoing, explicit, open and honest discussion about the trade-offs that are being made and their future implications and (b) a commitment at all levels of the organization (not just inside the product group) to not end up behind the 8-ball. Companies that embrace this broader concept of fluid architecture can rebuild themselves on the go and move at the pace of today’s business.
TelecomPk.Net is a leading source of information and analysis about Pakistan Telecom industry.
Loading ...
good article. however, i do have my reservations on open source software, much of which were fueled by comments on an article at coding horror at
http://www.codinghorror.com/blog/archives/001082.html
apart from that, i believe any company giving up its fluidity is essentially inviting disaster. I recently read a book called “from good to great” on building world class companies and one of the recurring patterns in the book was that the world class companies known to the world today started off very differently in their early days. Just take a look at 3M, which today we relate with almost all sorts of office supplies, from post-its to disks and cd’s, started off as a mining operation (the 3M originally stood for Minnesota Mining and Manufacturing)
in our own industry, one of the more recent examples have been that of the lakson group, built upon and famous for its tobacco brands Gold Leaf etc. Today, they’ve sold their tobacco division and making high value investments in their tech business, namely cyber.net and lakson business solutions (formerly CRISS) as well as other verticals.
I also believe that open source has its limitations. Always use your judgement and not leave all eggs in one basket.
Everyone thinks that they are following a flexible and fluid approach but its harder than it sounds.
In response to the previous comments, it should be noted that open source software is not very different from any other software. “Open source” simply means the sources are open. It has no implications about the development methodology used. Also, its not commercial vs open source. There are a lot of commercial open source projects.