Align IT and Business in an Agile Manner

Agile Software Development

Subscribe to Agile Software Development: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Agile Software Development: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Agile Development Authors: Elizabeth White, Jason Bloomberg, Plutora Blog, Liz McMillan, AppNeta Blog

Related Topics: Agile Software Development, CTO Journal, SOA Best Practices Digest, SOA & WOA Magazine, Telecom Innovation

Televation: Article

What Is Service Orientation?

On the importance of achieving true business agility

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.
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.
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 scale2 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.3
  • 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.

1 The original quote is commonly accredited the German theoretical physicist and Nobel Laureate Albert Einstein (1879-1955) and is about any problem set.
2 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.
3 For ease of reading, I’ll refer to monolith for the entire group of similar emerging behaviors and phenomena’s.

More Stories By Martin Kaarup

Martin Kaarup began his professional career over a decade ago as a system developer on location-based mobile phone services. During that time he participated as lead developer in pioneering unique state-of-the-art location-based services for the European and Asian markets, such as low-cost fleet-tracking using antenna triangulation and applications for utilizing customer positioning data for demographic use. He also participated in building location based games, such as treasure hunts and country-wide Dungeon & Dragons-based games merging www, wap and sms technologies.

Later, he shifted to the financial sector in Scandinavia where he worked as an enterprise architect building, extending, and delivering advanced fund data solutions and services designed specifically for the pan-European Fund Industry.

Today, Martin is an employee at the Swedish consultants company Avega Group, where he focuses his expertice on consulting companies on strategic and enterprise wide issues.