Creating an Agile Enterprise: Focus on Architecture, not Methodologies. Despite continuous advancements in the field of IT and application development, IT challenges have continued to haunt enterprises causing numerous crisis situations:
- Difficult and complex upgrades
- Extremely high cost of ownership
- Counterproductive cross-functional processes
- Apps failing to deliver as per business requirements
- Inflexibility creating restrictions in the business process change
When Agile is Not so Agile
The issue is that IT often defines “agile” in many different ways than businesses do. One can find many IT shops where agility is being measured in so many different terms including story points, velocity, burn-down charts, and other data points and metrics; all of those terms are focused on analyzing how well a team is performing with respect to historical numbers. Now the interesting thing is that most of these numbers really don’t measure business agility. Instead of measuring agility, they are more leaned towards measuring IT productivity, and both metrics are quite different from one another. For instance, a team can be highly skilled at building stuff, which is quite different from the process of achieving corporate-wide agility.
Under many circumstances, companies take the term agile literally and begin to build stuff without visualizing how their architecture will manage the demands of business in the future. As a result, they often end up developing a rigid and fragile system lacking the ability to manage the required speed of the business to achieve a truly agile status.
Creating an Agile Enterprise demands to be measured keeping the viewpoint of the target customer in the center. Undoubtedly, enterprises should keep a close watch on their teams’ performances, but they also must remain focused on metrics like new customer registrations, customer satisfaction, revenue growth, new features that are based on time periods (month, quarter, year), etc.
Being Truly Agile
The vision to become a truly Creating an Agile Enterprise involves agility being a driving force in their underlying architecture. Surprisingly, one can find a large number of projects in which the first thing that their management team has planned to build is a user interface (UI). UI is surely one of the critical aspects for any successful project to consider, but there are other more important areas that demand to be given priority by organizations before building their user interface; those areas include planning to attract new customers onboard, figuring out ways for the server team to support their underlying infrastructure and also ways in which their operation team can extend support to customer calls, and ways to accommodate new customer requests through rules or configurations.
Instead of focusing on other priorities, the norm is to create a web page first, start pitching customers, and consider other aspects later. That approach may work for a cash-starved startup but may create major crisis situations for many enterprises. Architects and business partners are required to collaborate upfront and focus on a far-sighted vision involving what their services and products should do. This is the stage where the architects start exploring their requirements for abilities including reliability, scalability, portability, maintainability, etc. This stage is followed by the creation of user stories to be included in the roadmap.
In most instances, a system does not require the highest level of scalability from the start, but some degree of thought needs to be implemented in the initial architecture; it will assure an enterprise that making changes within the system to accommodate future growth will be more streamlined and easier. Systems taking more time to make low-impact changes will face challenges to survive in the modern world of cloud, mobile, and web, mobile.
In a Nutshell
An organization can be good at agile software development, but that does not mean that the organization has achieved true business agility. The true purpose of IT is to extend support to fulfill business goals; those goals are often linked to metrics like customer satisfaction, revenue, and market penetration, while IT, in most cases, focuses strictly on metrics like story points and velocity.
An enterprise can call itself agile provided that it has acquired the ability to deliver products and services at speeds matching customer requirements. Irrespective of the speed of IT in cranking code, what really matters is that the services and products are in-line with the supply and demand economics of target customers.
With respect to agility, it is highly critical that the underlying architectures being built involving the products and services have been built to be configured, automated, and modified for IT to become truly agile.
To know more or to talk to our expert write to us today: marketing@motivitylabs.com
