Businesses tend to focus their architecture on efficiency instead of agility. This clear distinction between optimising for the known versus optimising for the unknown inherently counteracts on businesses in their effort to seize any of the new opportunities that arises around them.

This article emphasises the importance of architecting enterprise wide systems with quality capabilities and a service orientation that more properly reflects business agility and enables new opportunities to create much more focused, efficient, and adaptable organisational structures.

Describing the problem domain

Desirable as it might be, delivering agility is not straightforward as the following obstacles must be overcome: ^{[7, 9]}

• Organisational culture and project orientation. In the same way that project orientation inhibited the reuse of components, it may also stifle agility. The needs of the business as a whole will not be considered, and generalised services that may be applicable elsewhere will not be delivered.
• Short term thinking. The pressure to meet immediate requirements leaves no scope to discuss future needs. This might not in itself prevent IT from trying to introduce the principles outlined here, but make it difficult to discuss and agree them with the business.
• Risk management culture. Without strong risk-analysis processes, most companies gravitate towards one of two extremes, over-exposure or over-insurance. These qualities are reflected onto all aspects of the company.
• Business secrecy. Whilst the business may desire agility, it may not necessarily want to share the business strategies with IT that might require agile solutions.
• Ability to abstract and generalise. The skills required are not always common in the technical staff, particularly if it also requires sufficient familiarity with the business to be able to abstract and generalise the business concepts.

Furthermore it is important to notice a special trait that is unbeknownst to many business and IT professionals, but is accepted as the root-cause of this entire problem domain, namely that every system built inherently restricts the organisation into a certain way of thinking and cements the companies into functioning the way business worked when the system was built.
Despite recent improvement the last decade many companies still build systems that are legacy the moment they are turned on. ^{[2, 10]}

Figure 1: Change requests reduce the agility of architecture over time without thorough analysis. ^[16]

It follows that, delivering agile business capability is more a consequence of thorough analysis of the business need with agility in mind and careful design of the solution that is architected for agility, than merely implementing an agility-enabling technology into the existing architecture. ^[9]

If businesses are to become more agile then they must address these issues. Business leaders cannot continue to bemoan the IT department’s apparent lack of responsiveness to change when its own practices can create the above obstacles. Similarly the IT department must also play its part in designing agility into their solutions and not delegating it to the IT vendor’s latest ‘magic bullet’. ^{[3, 9]}

Changing our mind-set about how we work together with IT is necessary, because the existing problems, embedded deep into the architecture, cannot be solved by the same level of thinking that created them.^{1 [2]}

The intelligble question to ask

What proven method should you follow to make your technology landscape more responsive to changing business needs?

Any of the following compelling forces would justify using the solution described in this article: ^{[1, 13, 15, 18, 19, 20, 25]}

Figure 2: Business goals for service orientation. ^[13]

• Reduce total cost of ownership. Leveraging existing assets will reduce the cost of maintenance and free up internal operations resources that is spent on re-active activities such as maintaining legacy systems. This reduces the total cost of ownership. The resources can then be consolidated or re-directed towards forward looking and value-added activities, such as innovation – a core characteristic of Lean production.
• Improve capability (Quality of Service). Trapped inside your company’s processes are activities and enterprise-scale data that can now be swapped, bought, and sold thanks to technology and business methods for catching the long tail. These new productions of scale² opportunities are predicted to open up entirely new fields in, for instance the banking, telecom, and generation-old retail industry – and its first come first served.
• Improve market position. Many profitable business change cycles have added so much inertia to the technical architecture which wasn’t designed for such adaptability in the first place. Emerging behaviours such as monoliths, silos, isles-of-automation, and phenomena’s such as spaghetti code, or a combination of these threatens businesses on both tactical and strategic terms, namely by increasing time-to-market towards both known and new markets, and by introducing unnatural risk into any change management considerations for the technical architecture.³
• Support improved business processes. Unfortunately for the company, the existing architecture isn’t designed for improving business processes or automation of existing labour-intensive processes (straight-through-processing). The silo-based architecture forces sub-optimisation of even the simplest core business processes, for instance adding a new product to the business portfolio also requires unnecessary rewiring of related processes.

¹ The original quote is commonly accredited the German theoretical physicist and Nobel Laureate Albert Einstein (1879-1955) and is about any problem set.
² Companies like Google, YouTube, PayPal, Facebook have changed the scope of their business by taking advantages of their demographic data. However, the market for demographic travelling and buying habits are not fully explored yet.
³ For ease of reading, I’ll refer to monolith for the entire group of similar emerging behaviors and phenomena’s.

• Kyle Gabhart's Session to Explore Selective Service Orientation at SOA World Conference & Expo
• Exclusive SOA Web Services Journal Briefing – Thomas Erl On SOA
• Demystifying Service-Oriented Architecture