Since the launch of the agile manifesto we have seen different incarnations of agile processes that purport to solve all our problems in terms of delivering software on time and on budget. Most of these processes have had varied success and in some cases they have muddied the waters with regard to where software architecture sits in all of this.
The challenge of seeing where software architecture fits in has been further compounded by the way our domestic markets are in transition and abroad we have seen the idea of startups as economic growth engines taking hold; France (with Station F being an example of such initiatives), Israel, India and most recently Singapore. For us back here in the United States we are starting to see places like Los Angeles, Austin, New York and Colorado Springs among others start to move towards being startup hubs with blitzscaling at their core.
Central to blitzscaling is the idea of rapid growth at the expense of efficiency in order to capture market share early in the company’s life cycle. With this comes budgetary pressures and rush to market which at times can lead to organizations turning their agile processes to be task oriented with software architecture work taking a back seat leaving less time to plan for future proof development, scalability and maintenance. On the other side of the equation startup organizations do not see a place for agile processes for software architecture resulting in agile processes being reserved for companies that are mature and are looking for more structured approaches to software development.
At Eureka we have spent and do spend the necessary time for mapping the technical path while being aware of this new growth reality.
Software architecture can be utilized by us and leveraged by our partners to create:
- High performing teams
- Better team culture
- First to market products that blitzscale
- Better bottom lines
Our view is agile processes are malleable and can be adapted to suit any organization’s maturity level with software architecture being an enabler from day one on the project.
In future posts we will explore how software architecture contributes to high quality software products viewed through the various prisms mentioned above.