Increased business and IT agility

This is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.

Rigid systems can be a pain.

Being agile means being willing and able to speedily respond to change requests – especially unforeseen ones.

Business people want systems that can be changed or replaced quickly and easily.

At least, they want this after they have bought the system, but not so often before they bought it.

So, facilitating system change is an aim of both strategic enterprise architecture and tactical agile development methods.

There are difficult problems here. To begin with; there is an accounting problem.

Business people don't acknowledge that computers act as employees in doing work for the business.

They count IT costs as a percentage of "overheads" rather "operational costs" like workers' salaries.

There is a case for saying this undervalues IT.

But having said that, thoughtlessly throwing more money at IT is probably not the answer.

There is a human v computer nature problem: humans are flexible; computers aren't.

Human actors, given a vague direction, can work with almost no instruction, making up their roles and rules, and changing them, as they go along.

A computer actor’s roles and rules must be specified in detail so excruciating and obscure as to be incomprehensible to most.

This requires specialists, first to configure and code a system, and then to maintain it.

The gulf between managers and configurers/programmers is wide, but they agree on one point.

Managers don't want to pay people who understand the system configuration and code to sit around waiting for a change request.

Configurers and programmers don't want sit around doing nothing (probably for low pay) either.

Zachman's answer - to document the code in five successively more abstract levels of description - is impractical.

Some general principles are:

· People are more flexible than software

· Software is more flexible than hardware.

· Behaviour that is prescribed (by specifying rules in processes) is less flexible.

· Behaviour that is made configurable (by specifying rules in data variables) tends to be slower.

· There are trade-offs, such as between global integrity and local agility, as might be shown below

.

Business process “Operating model”	Low standardisation	High standardisation
High integration		Global integrity
Low integration	Local agility

Q: How to make business systems agile?

There are many approaches, not necessarily sympathetic to EA.

We can isolate a system - decouple it from other systems.

The EA vision of unification challenged by the trade-off between global integrity and local agility.

Standardisation and reuse widens the impact of a change to the standardised/reused thing.

Integration widens the scope and complexity of the system to be changed.

Reuse of any shared resources raises the question of who pays for changes.

These things may increase agility in some ways, yet decrease it in other ways.

We can minimise specification detail and delegate.

Sometimes, hiring and motivating skilled people is OK.

Give them a goal (make a profit, save the white rhino from extinction) and monitor only how well the goal is met.

The idea behind much “out sourcing” is to detail the services that must be provided to customers, and monitor the delivery of those services against that specification.

Here, agility means the ability to change the service specifications (without worrying about the system’s internal processes) or replace one service provider by another.

Architects do look to encapsulate systems behind service contracts and SLAs.

This idea is fundamental and essential in computer activity system design.

But since it constrains the behaviour of a system to what is defined in its interface, it can inhibit the capability of human activity systems.

Naive service contracts can reduce the value that humans bring by way of flexibility and creativity.

The more a business wants to standardise and mechanise the activities of employees and customers, the more that it prescribes the processes they follow in some detail.

So, another route to agility is needed.

We can proceed by changing a system in short-cycle system generations.

Truly continual change undermines the concept of a system – there is no system.

The agile principle of short-cycle change reduces the risk of change and allows for frequent review and adjustment of the longer term target, however near or far that target is.

Software development teams are encouraged to plan and complete short (say 3 week) “sprints”.

A challenge for EA is to apply the same principle to long-cycle (say 3 year) strategies.

A strategy is naturally "pre-emptive" in so far as it forestalls or inhibits options other than those in the strategy.

A strategy's reach into the future is as near or far as you want it to be.

The advantage you get from shortening the planning cycle is the ability to change the strategy more often, to reflect a changing environment.

But there are disadvantages.

Once embarked strategy 1, you spend money down that path, some of which will be wasted when strategy 2 is announced.

A question then arises as to whether the business case for strategy 2 should account for money wasted on strategy 1.

Worse, if people know or believe the strategy is to be revised in the near future, they will delay committing time and resources to it.

And they will start to second guess the next strategy.

So, there is a complex relationship between

· the target time horizon

· the length of the planning cycle,

· the faith of people in the strategy, and

· other factors not mentioned here.

In most planning, there as much, if not more, art and politics as science and numbers.

Q: Why do agile software developers deprecate EA?

Software systems are necessarily specified in excruciating detail that only specialists can understand.

If architects are to maintain manageable descriptions of software systems, they must do it in higher-level more abstraction documentation, say use case definitions.

The challenge is to maintain higher level use case definitions alongside the software, and ensure both are kept in step.

To speed up change, developers change the bottom-level performable software processes before updating any higher level abstract descriptions maintained in an architecture repository.

And so, they perceive architectural documentation as a drag to change.

EAs work at the highest and most abstract levels of design and planning.

Abstractions may suit an audience of business managers, and get things moving.

But they may not speak to people working at lower and more concrete levels.

What to do? EAs teams should engage – practically and socially – with solution architects, technical architects and software architects.

Q: What about agile IT systems?

Agile software development refers to the ability of an application development or maintenance team to change an application according to unforeseen and mostly functional change requests.

Agile IT refers to the ability of an IT service provider to change the IT services it provides according to unforeseen and mostly non-functional change requests.

This may involve changing, reconfiguring, replacing or moving technologies such as client devices, server devices and networks.

Challenges to IT agility include:

· Changing purchased technology resources is costly

· Changing to meet higher scale, availability or recovery needs may be difficult and costly

· Changing security features may be difficult and costly

· The need for more skilled technology designers and operators

· The need to train people up in new technology generations

· New technology may not perform as expected - leading to down time.

· More time and effort needed for short-cycle planning of technology changes.

To achieve agile IT, you need agile IT systems.

Virtualisation (turning hardware into software) is obviously a key to agility.

But it leads to server sprawl and increase complexity.

Which is why you need more skilled technology designers and operators.

Q: How can software be agile when business data and rules are locked up in technologies?

EA is about systems that follow or apply rules.

(Where business people make and change their rules and processes in an ad hoc way, there is no tractable system to work with.)

Systemisation of rules and processes is hard and painstaking work - often more difficult than was expected by those with the vision.

It can be difficult to engage business managers, even system users, with the work.

Exception handling (20% of cases?) can turn out to be 80% of the complexity.

Making a system flexible, with configurable rules, takes more time and money, and system performance is slower.

Technology vendors have a vested interested in getting us to document business data and rules using their technology.

If only we could separate our business data and rule specifications from their technologies!

Q: Do we expect to get more value from a system as it evolves?

You might hope there would be evolution by natural selection of the fittest solutions.

But I fear that doesn’t apply well to IT-based solutions, because if a solution is badly designed and inefficient, it is given more resources.

And given a good design, patches are plastered over patches until the original design is invisible and unmaintainable.

New systems often perform worse and sometimes deliver less than old systems they replace.

Q: Is cyclical design inevitable? Old designs have to be replaced with new designs (new legacy)?

It does seem inevitable, due to changes in languages and technology platforms, functional and non-functional requirements.

It is in the interest of IT product suppliers to develop new versions and withdraw support for old versions.

The trouble arises where current systems are valuable, but large and complex beyond current understanding.

To rebuild them is expensive, and we risk that they don’t work as well.

We may lose features - ones not recognised or understood by new system designers.

Q: So what are you saying?

It is easy to throw the words "value" and "agility" into an elevator pitch, but the implications and practical recommendations are rarely clear.

Sponsors need to be clear about what they mean by agility and what it takes to get it.

Managers press architects to "agile development", but often really mean "do this faster and cheaper"; without acknowledging the role they (or their employees) must play in the development process.

The quickest cheapest solution can conflict with long-term strategies, principles, policies or standards.

Agile development is difficult in cases where it is impossible or unacceptable to release a partial system.

Agile development may not result in agile systems.

Principles such as "you ain't gonna need it" and "do the minimum to deliver" mean the system does the minimum to implement currently-defined rules.

The term “agile architecture” may be seen as an oxymoron.

Architects should not have to change their architecture every time a change request is made.

An architecture that is frequently changing may be regarded as a poor architecture.

Agility means different things at different levels of design, and requires different approaches.

Within the architecture landscape, different systems, and layers of one system, have different change characteristics.

Sponsors need to understand and commit to doing what it takes (time, effort and money) to get the agile systems they want.

And not to be seduced by thinking any technology (middleware or other) will guarantee agility.

“Some systems need to be very predictable & stable over time.

Make sure these systems don't negatively impact the change/innovation rate in layers closer to the consumers.” Joakim Lindbom

Correspondent: The IT department cannot afford to give every executive their own IT.

It needs to get better at making executives thinking the IT they are getting is exclusively their IT.

It must respond to a sponsor as (or nearly as) if they were the only person calling the shots on IT prioritisation.

Reply: As a rule, sharing a resource hinders agility for any one sponsor of that shared resource.

References

Ref. 1: TOGAF 9.1, The Open Group.

Ref. 2: Oxford Dictionary of Proverbs. Cf. 1942 G. Ciano Diary 9 Sept. (1946) II.

Ref. 3: Heylighen F. (1992): "Evolution, Selfishness and Cooperation", Journal of Ideas, Vol 2, # 4, pp 70-76.

Ref. 4: “EA as Strategy” Ross, Weill and Robertson.

Ref. 5: ArchiMate v2 standard, The Open Group.

The papers on the “Enterprise Architecture” page at http://avancier.website contain much advice relating to EA.

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0 04/02/2015 02:09

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.website” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this work, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org