Jaywalk

This morning, ITviikko and Efecte jointly organized a brunch about ITIL (Information Technology Infrastructure Library).

Jaan Apajalahti, CEO, Efecte, argued that IT should be viewed as a business activity that needs to offer cost-efficient and competitive IT services for the enterprise. The internal IT organization must be competitive with and comparable to solutions offered by external vendors. The transformation of the IT organization from a “fire department” to a value-adding, strategic function requires enhanced communications and better coupling between business and IT. ITIL is one framework to facilitate this.

Service Level Agreements (SLAs) should define the entire operations of the IT. If there is no SLA, why is the service provided in the first place, as the business does not know it is buying the service? Apajalahti advises to make a service catalogue, agree upon service levels and price them together with the customers (the business). He visioned about an agile “IT-ERP” that would provide a unified view and support the versatile processes and data requirements of the ICT supply chain now and in the future. Such facilities would include ITIL processes, project management, procurement, invoicing, contracts, etc.

Seppo Saastamoinen, CIO, Tieliikelaitos (Finnish Road Enterprise), provided a customer case on employing ITIL in an IT organization. He emphasized Big Picture thinking but step-by-step approach, good communications and management support. ITIL should not be copy-pasted as such but be adapted to the organization’s particular needs. If somethink is not broken, it must not be fixed. Business benefits should drive the implementation.

Saastamoinen argued that while consultants should be used to get things going, the basic work should be done by the IT organization itself for the sake of learning. He also advocated investing in software tools and integrating and automating wherever possible. As the realized benefits of their ITIL project he mentioned the specification of an internal IT profit centre, “good bureaucracy”, decreasing number of tickets and accrual of documentation.

Petri Väyrynen from Wakaru Partners asked rethorically “IT and common sense — can they be combined?” and concluded that yes, they can. He argued that IT requires systematic management of people, processes and technology and that ITIL helps to systematize it — ITIL is essentially a management system. Business benefits can be achieved by setting clear objectives and measuring them. Some benefits can even be achieved fast and easily but it requires hard and systematic work.

Eero Aho from SysOpen Digia also referred to common sense by saying it is applied in best practices such as ITIL. This process-oriented collection of methods and documents provides a common vocabulary among the stakeholders and can be applied to the provision, acquisition and production of IT services. It is not “off-the-shelve” but needs to be adapted to the organization (just as Saastamoinen suggested). What makes ITIL special is that it is independent of the service provider and applicable to a variety of organizations.

In the end, there was an SMS poll in which the audience could vote with their mobile phones. The question “Is your IT organization aligned with the business objectives?” was answered as follows: Yes 40 %, No 60 %. The seminar was graded in the scale of 1-5 as good: 3: 14 %, 4: 54 %, 5: 32 %.

Today, I had the great privilege of attending a Web presentation by Scott W. Ambler on Agile Mode Driven Development (AMDD).

He started his presentation with a warning that he is “spectacularly blunt at times” and that some of his new ideas may not fit well into existing environments. Some ideas will challenge existing notions about software development and likely confirm one’s unvoiced suspicious. Ambler encouraged to be skeptical yet open minded but warned about making any “career-ending moves” based on these ideas.

Ambler cherished the idea that Agile Modeling embraces change. Change is characteristic to software development as people are not good at identifying what they need, people change their minds and the business environment changes. People ask for everything they could possibly want and developers do not read and/or understand the requirements. As a result of “Big Requirements Up Front (BRUF)” approach, 45 percent of software functionality is never used! (Standish Group, Chaos Report).

In the agile approach to change management, each iteration implements the highest-priority requirements. Each new requirement is prioritized and added to the stack. Requirements may be reprioritized or removed from the stack at any time.

Agile Models are just barely enough! They fulfill their purpose, are understandable, sufficiently accurate, consistent and detailed, provide positive value and are as simple as possible. There is no starting point, but the modeling switches back and forth between models: each model is used where it is appropriate. This requires sophisticated skills from the developer, as there is no cookbook methodology. Ambler argued that the use of specialists for any specific kind of modeling is wastage and that there is need for a greater range of modeling skills.

According to Ambler’s definition, Agile Modeling is a chaordic, practices-based process for modeling and documentation, a collection of practices based on several values and proven software engineering principles.

Ambler emphasized a number of critical concepts of Agile Modeling that bear marked resemblance to XP practices. Among other things, he argued for modeling with others as a means of quality assurance as opposed to a rigorous review process (cf. pair programming), active stakeholder participation (cf. on-site customer), modeling in small increments (cf. continuous integration) and collective ownership of models. He did not deem consistency as important, but urged to “update only when it hurts”.

Accordingly, Agile Modeling values are:

• Communication
• Simplicity
• Feedback
• Courage
• Humility

Ambler sees that only around 5 percent of agile modeling projects will employ full-scale MDA, since it requires really sophisticated developers and organization.

As a conclusion, Ambler stated that modeling is an important part of every software process, including XP and that it is an important communications technique. He also argued that UML is not sufficient for business application development, but one needs to think outside of the UML box.

Five years ago, I outlined a model of organizational learning: Middle-Down-Up Management. Revisiting this model, I can see it is in perfect line with the anatomy of Agile Enterprise Architecture as described in my earlier posts. Figure 1 depicts how the levels of enterprise architecture correspond to the model.

Figure 1. Organizational Learning and Enterprise Architecture.

On the strategic level, business activity is monitored (BAM) through the management process, exposing organizational theory-in-use, or actual behavior,? in the form of real-time management dashboards facilitating strategic decision-making. The shared vision of the organization is built as a steering process of external adaptation and internal integration. The output of this process are the new and revised models describing the business processes on the highest level. Simulation capabilities are also employed as the means of optimizing the processes.

The tactical level is about coordination and? associated with? team learning. The strategic intent of the top management is translated to unique end-to-end core business processes. These processes can be configured by composing underlying context-independent services and coordinating the interplay of executable processes. Choreography is the prevalent means to describe relatively static collaborative processes; new concepts are emerging to address more dynamic? collaborations. This is where the team learning occurs: the coordination of the collaborative effort requires a significant amount of dialogue between the process participants. Team learning also has an effect on tacit knowledge within the organization through the leadership process.

The operational level embraces the operational and information model of the organization in the form of services. The services are context-independent, idempotent faculties optimized to perform their predefined function. Typically, orchestration describes the sequence and conditions in which the service? accesses underlying resources, binding? them to its execution context. Thus? this level? corresponds to personal mastery: the purpose of orchestration is to optimize resource utilization and streamline service efficiency against some performance measure defined? by the management process.

The model reflects the reality as perceived by the organization. It is the vast repository of “sources of truth”? dispersed in enterprise information systems and databases, the knowledge of the organization. Thereby, it can be equated to mental models in the Middle-Down-Up model.