According to this force-field analysis, change occur.

Use Force Field Analysis for Each Project

As mentioned in Chapter 5, force field analysis uncovers the driving and restraining forces for the desired change related to the candidate project. You can get a group involved with the visual nature of force field analysis using flip charts or a whiteboard. Having a group inspect the completed force field analysis may allow you to discover that a project can be made smaller. For example, you may find that a restraining force is the lack of a tool to develop the service interface. You could decide that experimenting with development tools is a project unto itself. Therefore, the candidate project could be divided into two projects. One project is tool experimentation and selection. By dividing the candidate project into two projects, you eliminate a restraining force on the original candidate project and you get two smaller projects—one that is only tool selection. Presumably, the selected tool will also be used in future projects.

What If Things Are Not Going as Planned?

The example development illustrated in Figure 11.7 addressed the design-related restraining forces for adopting an SOA. Those design issues appeared in the force field analysis illustrated by Figure 6.9 and are as follows:

Deciding what data to route

Delays getting data updates distributed

Deciding what data to warehouse

Delays in getting data to the warehouse

Redundancy of data

Data quality issues

Effects on operational systems for up-to-the-moment data requests

Identification and design of services

But what if things are not going as planned? I’ll go back to the story about C. R.’s organization to illustrate problems and possible responses.

Figure 12.3 represents, at one point, the systems supporting the SOA for C. R.’s organization (Figure 11.7 is essentially a subset of this figure). To add more detail to the story, let’s say two issues appeared at this point in the use of the SOA:

The data warehouse was growing much faster than expected.

The response time of the services provided by an internal system was inadequate and the indeterminate access requests were adversely impacting the operational system. This is the issue illustrated by Figure 12.2.

The response time of the services provided by an internal system was inadequate

The second issue can be problematic. C. R.’s organization, like many others, was not in a position to change the internal system that was being adversely affected when used as a service. One solution is a middle-tier architecture that uses persistent caching.

Basics of a middle-tier architecture

This section goes into some technical detail. The purpose is to show that the systems underlying a service can go through significant changes, and yet the services themselves are affected very little.

A middle-tier architecture is one way to leverage the use of existing systems and databases. The middle tier changes where integration occurs. Instead of directly integrating existing systems and databases, a new layer is developed so that the integration occurs in the middle tier. Moving integration to the middle tier is the solution used by C. R.’s organization to address the conflict between indeterminate and operational access.

Figure 12.5 illustrates the basics of a middle-tier architecture2 that uses an application server and a middle-tier database. The middle tier is above internal systems. One of the internal systems that we have covered so far is at the bottom of the figure. It is also used as a service.

Figure 12.5. Middle-tier architecture.

Note that the adapter is at the bottom of the middle tier, above the internal system as it was in Figure 12.4. Since this application server is presumably new development, it can use the same semantic vocabulary and Web services message format as the ESB. An adapter is not needed for the application server.

Figure 12.4. Using a PaaS cloud provider for a big data store and BI/analytics.

Persistence in the middle tier

It is possible to add persistence to the middle tier. Adding persistence to the middle tier makes sense in situations that either have too much data to keep in the application server cache or situations where you need the protection of persistence to make sure no data would be lost before it can be written to the internal system. It can also be a way to boost performance of services provided by an application server when it needs to access data. Middle-tier persistence, however, will require additional development.

A persistent cache adds capabilities to the in-memory cache. These include:

▪

Expanded caching

▪

Protected caching

▪

Caching performance gain

The examples assume that a database will be used in the middle tier to provide the persistent cache. A database manager ensures that all transactions will be recorded properly and has recovery and backup capabilities, if needed.

Expanded caching

There are several ways that a cache could be populated:

1.

On an as-needed basis. An instance moves into the cache only when a program requests to read the values of the instance.

2.

Fully populated at start time. All instances needed in the cache are populated when the system starts up.

3.

A combination of the first two. An example is populating the cache with the most likely instances that are needed and then moving additional instances into the cache when a program requests to read the values of the instances.

In any of these cases, the cache size simply could be too large to efficiently keep in memory. A middle-tier database could act as an expanded cache to offload some of the data cached in memory.

Using a middle-tier database as an expanded cache adds options when the underlying internal system is updated. The updates could occur as they happen or at intervals, depending on the needs of the organization. For example, one option would be to populate the middle-tier database from the internal system at the beginning of a business day. All updates could be kept in the middle-tier database. These updates could then be written to the internal system at the end of the day or at intervals during the day.

Protected caching

If all middle-tier cache updates are written to a middle-tier database, then the cached updates are not lost if the application server should fail. They can be recovered from the middle-tier database when the application server is restored. This, of course, would not be necessary if updates to the internal system are made every time an update occurs. That, however, can create a performance hit to the middle tier, as will be discussed in the next section.

Caching performance gain

If the middle-tier database uses the same data model as the middle-tier cache, there is a good chance that performance will be significantly better than if updates were written to the internal system as they happened.

This performance gain is possible assuming:

▪

The internal system uses a data structure that is different from what is needed for the service. Chances are that this is true if the internal system has been around for a while.

▪

The application server uses a cache that matches the needs of the object program in the application server. This cache could use either an object, XML, or other NoSQL data structure.

▪

The middle-tier database uses the same data model as the cache.

Given these assumptions, the time it takes to write an update to the internal system will most likely take longer than writing to the middle-tier database. As the complexity of the model used by the object program in the application server increases, the difference in the time it takes to write the update to the middle-tier database versus the internal system increases. This is because the mapping complexity also increases between the data model in the cache and the model in the internal system. The mapping simply takes time and costs performance.3As a result, an update to a middle-tier database can be significantly faster and allow processing to resume much sooner than if the update was to the internal system directly.4Figure 12.6 shows the sequence of this processing.

Figure 12.6. Using a persistent cache in the middle tier.

Middle-tier databases

There are many database options available for middle-tier persistence, because middle-tier databases essentially store temporary data. This is in contrast to internal system databases that are often seen as databases of record, which are expected to last “forever.” When you are considering a database product for an internal system, it is reasonable to choose a database management product from a well-known, established vendor.

In contrast, middle-tier databases—because they are temporary—open up the possibilities of using technologies that might significantly improve performance and reduce development as well as maintenance costs.

There are many issues to consider in selecting a middle-tier database. A discussion of those issues goes beyond the scope of this book. More information on middle-tier persistence can be found at http://www.service-architecture.com/object-oriented-databases/articles/middle_tier_architecture.html.

Putting it all together

Figure 12.7 shows the systems supporting the SOA for C. R.’s organization after addressing the two issues that appeared after developing the enterprise data warehouse (EDW) and using an internal system as a service. The customer relationship management (CRM) from a software as a service (SaaS) cloud provider was also added for completeness.

Figure 12.7. Systems used by C. R.’s organization that include a PaaS cloud provider, SaaS cloud provider, and middle-tier persistence.

A.3.4 Identify the organizational culture

Organizational culture is always important for organizational success and every organization has its own distinct culture. To manage information risks, you have to understand the culture in the particular organization, then adapt and choose the methods that you are using for assessing and treating information risks so that it really fits with the organizational culture.

According to Buchanan and Gibb (1998), there are two different approaches to identify organizational culture:

Stakeholder analysis (Grundy, 1993)

Force-field analysis (Lewin, 1947)

While stakeholder analysis helps to diagnose key stakeholder influences on the information strategy, Lewin’s force-field analysis identifies the enabling and restraining forces that affect the information strategy. However, you do not need to analyze organizational culture with formal methods. The easiest way is to keep your eyes and ears open when you talk to people and try to identify cultural patterns. Keep these cultural patterns and characteristics in mind when you conduct the information risk assessment and treatment and whenever you communicate and consult with stakeholders as part of the TIRM program.

ACTION TIP

The acceptance of different methods for business process modeling differs from one organization to another. Aim to understand the culture and adapt the choice of methods and techniques to it. Make sure you communicate in an appropriate language, one that not only the stakeholders speak but also that reflects their culture.

Finally, the attitude toward information and its perceived value is an important element of organizational culture for information management and should be investigated during interviews with employees and managers.

EXAMPLE: TIRM PROCESS APPLIED AT A CALL CENTER

The culture in the inbound department is very cooperative and therefore information is freely shared whenever needed. As call center representatives often get rewarded on the basis of the level of their individual sales performance in the outbound department, the culture there is less collaborative with call center representatives being less eager to help each other and share information and knowledge.

Describing transformational leadership

Many studies have been undertaken to discover what ‘transformational leadership’ looks like, to analyse what sets transformational leaders apart from other leaders, and indeed to discover what abilities, skills and qualities are required by those working, or called on, to transform organisational behaviour.

Handscombe and Norman (1989) identify the importance of a management ‘focus on corporate issues and not functional change’ as one of the key capabilities in the formulation and implementation of a strategy for successful organisational change and development: ‘top management teams must address the fundamental strategic issues for the business, however difficult the resolution may appear. This must be done on a team basis and not by accepting functionality developed proposals. Opportunity identification and evaluation must be ongoing and not inhibited by bureaucratic procedures’ (p. 125). The importance of the organisation’s future shape and success, then, clearly overrides any current obstacles. While degrees of incremental change may form part of the overall change management strategy, there is no room here for minor tweaking on a procedural level, nor yet for a sentimental attachment to what has gone before. Existing cultural norms, then, must not be allowed to interfere with the achievement of an agreed future state, and the manner of accomplishing this is clearly differentiated from other types of change management.

As discussed above, however, the difficulties faced by organisations intent on achieving strategic change are found not so much in the creation of change strategies but in their implementation. Creating a vision is one thing – making it happen is quite another. Referring to Kurt Lewin’s seminal work on intergroup dynamics and planned change, Dawson (2003: 30) points out that:

Managing change through reducing the forces that prevent change, rather than through increasing the forces that are pushing for change are central to Lewin’s approach and his technique of force-field analysis … [and that he] maintained that there are driving and restraining forces that maintain the status quo and within which organizations generally exist in a state of quasi-stationary equilibrium. Thus, in order to create conditions conducive to change it is necessary to identify the restraining and driving forces, and to change one or other of these in order to create an imbalance … Once an imbalance has been created the system can be altered and a new set of driving and restraining forces put into place.

They must first disrupt and change the existing culture (‘the deep structure of organizations, which is rooted in the values, beliefs and assumptions held by organizational members’ (Denison, 1996: 654) in order to create an environment in which their vision can be enacted: as Sarros et al. (2011) observe, ‘In many instances, the type of leadership required to change culture is transformational, because culture change needs enormous energy and commitment to achieve outcomes’ (p. 294).

Handscombe and Norman’s emphasis on having the management team address the fundamental strategic issues for the business on a team basis is important here. Although the management team might, for strategic planning purposes, distance themselves from the day-to-day, functional operation of the organisation, they are in fact an integral part, if not the guiding embodiment, of its cultural structure, and so must change their own cultural perception before they can cascade their new strategic vision effectively to others. How effectively and consistently they model the new behaviour, and the methods they employ to motivate and influence the behaviour of their colleagues will, of course, dictate the pace and ultimate success of the transformational exercise.

McGuire and Hutchings (2007: 155–6) consider that

The concept of transformational leadership has altered our notions and understanding of leadership and its effects on individuals and organisations [and modifies] our perceptions of modern leaders from authoritarian decision-makers to instrumental facilitators … The appeal of transformational leadership lies in the ability of the leader to inspire followers to transcend their own interests and work towards the benefit of all.

In addition, Bass (1995) offers a very useful definition of transformational leadership as being composed of four dimensions:

Charisma: the leader provides vision and a sense of mission; instils pride, faith and respect; excites, arouses and inspires junior colleagues.

Individual consideration: the leader provides coaching and teaching; delegates projects to stimulate learning experiences; provides for continuous feedback; and treats each follower as an individual.

Intellectual stimulation: the leader provides employees with a flow of challenging new ideas; motivates followers to think in new ways; emphasises problem solving and the use of reasoning before taking action.

Inspiration: the leader acts as a model for staff; behaves in ways that motivate and inspire followers by providing meaning and challenge; communicates a vision.

One might add ‘trust’ to this list, since, arguably, a leader who fails to inspire trust in followers is highly unlikely to have much of a chance to display the other traits and skills illustrated above. Followers, especially those faced with change, need to be able to place trust in their leader even though they might not, initially at least, fully understand or support the need for the proposed changes to take place. This 'trust' might manifest itself in a number of ways: it might take the form of an implicit trust in one who has already guided them successfully through choppy waters on previous occasions, and has clearly demonstrated their own faith in the new direction; or it might be more tentatively offered to one who inspires trust in others by displaying both supreme confidence in their own vision and abilities and in the ability of their followers to accomplish the vision, and (importantly) has described their vision with sufficient detail and clarity to demonstrate clear-headedness in their strategic thinking.

Of course, those who need to rely on the latter approach, perhaps especially in the case of newcomers to an organisation, face the unenviable challenge of needing to remain at least one step ahead of their followers at all junctures. They need to continuously prove that their followers’ faith in them and their judgement is not misplaced: phrases such as ‘Trust me, I know what I’m doing …’ will only last for so long without positive proof that their decisions are the right ones, and that their chosen direction will deliver the vision they have been selling. However earned, trust can evaporate very quickly if followers perceive more than the occasional faltering step, and while tenacity might carry leaders past previously unseen obstacles, their followers need to believe that as many of those obstacles as possible have been foreseen, accounted for and addressed in the grand plan.

Further, if it is important that the leader inspires trust, it is equally as important that s/he gives trust to those who follow her/him. Change, of any nature, is not accomplished by one person alone, but in concert with many individuals, all working together to bring it about. An organisation is made up of individuals who, at all ranks, have a vested interest either in making change happen or in causing it to fail – or at least in watching cynically from the sidelines while a change initiative sinks without trace. People who feel trusted to take forward an element of the change agenda will, if sufficiently stimulated and inspired, work hard to achieve the goal they have been set – those who don’t feel so entrusted will be much more inclined to take no further part in the process or, at worst, will work against it, either overtly or covertly. Rumour and doubt spread furthest and fastest among the marginalised, and cynicism can quickly become subversion among the disenfranchised.

Tenacity, as mentioned above, can be a very useful trait in transformational leaders, as can a sense of humour. Almost inevitably, support from followers is unlikely to be unanimous and instantaneous in the early stages. It is also reasonable to assume that those who drive change are already committed to it, and have probably already, in their minds, arrived at the end goal. They are, consequently, eager to see the change put into practice, and it is easy for them to become frustrated at the delay while everyone else catches up – tenacity needs to be tempered by patience and an understanding that people move through change at different speeds, so that at any given time some will be further along the change cycle than others. Transformational leadership is a long game, and an awkward and often difficult one, especially given the necessary but for many quite uncomfortable and disconcerting changes in culture that underpin it. Part of the skill in achieving successful change lies in, I believe, keeping the end goal in mind while observing where colleagues are in the change cycle, and maintaining a sufficient, though probably uneven, forward momentum so that those who are further along than others do not lose their forward impetus while others are encouraged to catch up. A colleague once told me that towards the end of team meetings he would often put forward seemingly fanciful and spontaneous ‘What if …?’ ideas, announcing them as too far off the wall for serious debate but offered for discussion anyway. The discussions that followed were usually (though not always) light-hearted, and normally ended with his being gently ridiculed for wasting everyone’s time. It is interesting to consider how many of those ‘What if …?’ scenarios later found their way onto the agenda for strategic change, but irrespective of that the discussions had served their purpose, in the medium term, by ensuring that while some at the table had their interests peaked and their imaginations fed, others were either manoeuvred a little further along the parabola of change or cajoled into accepting the inevitability of change. It was important also that these discussions and debates were undertaken within a team setting. As Arnold et al. (2001: 318) comment, ‘Transformational leadership increases trust, commitment and team efficacy … Strong values and norms within a team are still important in that they have an effect on the commitment that is felt within the team.’ To have broken apart the shared commitment and mutual support engendered by membership of the team would have been counterproductive to my colleague’s objectives at that time, as that would have left those individuals who had yet to fulfil their journey through the change parabola feeling stranded, isolated, unsupported and unable to provide the necessary impetus and direction to their own followers. Transformational leadership is a long game, and one best played with patience, tenacity and skill.

Two final questions remain in this section: who are the transformational leaders, and where do they come from? Kelloway and Barling (2000) point out that ‘While there is little doubt that leaders’ use of a transformational leadership style results in positive outcomes, there remains the question of how organizations use this knowledge … [and that] recognizing that most organizations do not have the luxury of replacing all of their leaders with “transformational” leaders’ (p. 356), the central questions for organisations are whether it is possible to train transformational leaders, how this might be done and whether it makes a difference to organisational outcomes. Taking as their measures Bass’s transformational leadership qualities, as mentioned above (charisma, individual consideration, intellectual stimulation and inspiration), their studies show that, through the delivery of ‘statistically significant changes in transformational leadership resulting from the training’, the answer to the question ‘Can you train transformational leaders? … is an unequivocal yes!’ and that the ‘subordinates of trained leaders became more committed (i.e. loyal) to the organization than were the subordinates of untrained leaders … [also that] Perhaps more importantly, branch-level [performance] increased only in those branches where the manager was trained’ (ibid.: 356–7).

Through appropriate training, coaching and reflection, then, leaders are able to develop transformational leadership behaviours, and to display them consistently in their daily transactions. In this, perhaps ‘consistency’ is the most important key word – consistency of message, and consistency of delivery. While it is important, for example, that a leader should provide an accessible and appealing vision in order to inspire followers, that vision has to be consistently maintained throughout the exercise; a vision which is constantly remodelled is not only difficult to sell but difficult for followers to buy into. Those who have been inspired to follow their leader’s ‘new future’ vision will soon lose faith, both in the vision and in the leader, if their goalposts are frequently moved. Similarly, a leader who one day encourages follower interaction with new ideas, asking for input, feedback and reasoned argument in problem-solving situations, but who then closes down debate on important matters and delivers unilateral decisions on another day, will very quickly disincentivise followers from making a personal investment in the outcome, and from taking any responsibility for its success or failure.

It has been argued many times, quite justifiably, that leaders can emerge at all levels of an organisation, at different times, for different reasons and in different styles. However, as McGuire and Hutchings (2007: 155–6) illustrate:

The concept of transformational leadership has altered our notions and understanding of leadership and its effects on individuals and organisations … Indeed, research into transformational leadership shows that this leadership style converts followers into leaders and results in the motivational and moral elevation of both followers and leaders … [and that] The appeal of transformational leadership lies in the ability of the leader to inspire followers to transcend their own interests and work towards the benefit of all.

All this, of course, framed within the context of a recognised need for profound change. Perhaps what differentiates transformational leaders from others, then, are three things: the nature, depth and context of the change they need to deliver; the skills they employ; and the consistency of character and behaviour they display in order to deliver the change required of them.

In their 2007 study of Dr Martin Luther King, McGuire and Hutchings offer the following succinct observations on the nature of transformational leaders, drawn from his example:

Transformational leaders need to demonstrate a capacity to recognise the need for change and devise innovative strategies to enable that change to occur. Through questioning norms and assumptions and encouraging divergent thinking, transformational leaders stimulate increased autonomy and independence amongst followers … By becoming champions for change, transformational leaders can show followers the way forward and make them believe that change is both possible and worthwhile … One conclusion is, however, inescapable, namely that transformational leaders retain enormous power to realise substantial ground-breaking change for the benefit of individuals, organisations and society.

(Ibid.: 162–3)

Few could aspire to the transformational impact that Dr King achieved, nor yet the profound moral and societal change he inspired, but whether attempting to change the culture of a society or of an academic library, transformational leaders are children of their time – they emerge in answer to a particular set of circumstances, when profound change is most needed, and they employ their skills and traits of character to excite, challenge, coach and inspire their followers in such a way as to realise a future state that might otherwise have been impossible to achieve.

Structure of This Book

Part I (Chapters 1–4Chapter 1Chapter 2Chapter 3Chapter 4) begins with a high-level story of how a person on a business trip interacts with a SOA based on Web services and cloud computing. Each of these technologies is then explained in more detail. As Part I progresses, technical details are added to the story in a “peeling of the onion” approach.

Part II (Chapters 5–7Chapter 5Chapter 6Chapter 7) deals with the technical forces driving the adoption of Web services, SOAs, and cloud computing. Change in any organization can be challenging.

This part looks at the forces that help or hinder the technical aspects of change using a technique called force field analysis. Force field analysis is applied to various integration techniques related to Web services, SOAs, and cloud computing.

Part III (Chapters 8–10Chapter 8Chapter 9Chapter 10) focuses on the people involved in the change. People worry about the future of their jobs and learning new tools and technologies. An organization must address these issues and concerns to achieve success. This part uses the force field analysis introduced in Part II. Here, the analysis deals with man-aging the human aspect of the change that occurs with the adoption of a SOA with cloud computing, and provides tips on how to make development easier. Chapter 10 introduces an incremental SOA analysis technique that aims to improve the project selection process in a way that also improves the chance of success for the selected project.

Part IV (Chapters 11–14Chapter 11Chapter 12Chapter 13Chapter 14) shifts to getting started with Web services, SOAs, and cloud computing. Chapter 11 provides three basic experiments that use Web services and then uses the story of the business trip in Part I to address more advanced uses of Web services. It ends with a vision of what Web services might mean for the future. Chapter 12 provides design concepts and considerations along with staffing and change issues to take into account when establishing a SOA. It illustrates how properly designed service interfaces can make it easier for an organization to respond to the chaos of modern business. It ends with a discussion of SOA governance. Chapter 13 discusses a way to evaluate external services and the systems and hardware related to cloud computing that support those services. Chapter 14 summarizes the Web services, SOAs, and cloud computing related to the business trip described in Part I.

Part IV (Chapters 15–16Chapter 15Chapter 16) is a reference section. It lists various semantic vocabu-laries and provides a quick reference guide for the terminology used in this book.

Summary

This chapter focused on the technical change issues related to the adoption of a service-oriented architecture. It analyzed integration techniques that preceded SOAs and the ESB, which is often used in SOAs. At the end of the chapter, the analyses were assembled into a combined force field analysis of the technical change issues for adopting an SOA using Web services. The discussion showed that by combining these integration techniques:

The standardization efforts related to the use of Web services are assisting other integration techniques. This was shown in the weakening restraining forces for adopting an enterprise data warehouse and for ORB middleware.

Because the use of Web services does not require abandoning existing systems or data storage, this further reduces barriers to the adoption of an SOA as part of an integration strategy.

There are many driving forces for adopting SOAs.

Over time, many technical restraining forces will diminish and the remaining restraining forces will be typical business and design issues.

How does change happen according to the force field theory?

What is the force field analysis concept?

What is Lewin's force field theory of change?

What is force field change?