Enterprise Architecture

I use to read Yves Caseau’s blog on which the author scans enterprise organisation issues, tries to identify appropriate optimisation levers, and tests models which helps to validate control efficiency. Involved in Enterprise Architecture which is expressed by organisation, Y Caseau has already identified 5 levers for organisation efficiency :

• meetings
• hierarchy
• matrix structure
• lean and mean
• competences

Should this list be closed or requiring new entries ? Although some people think that organisation is far less important than strategy, it deserves to be properly studied since without well shaped organisation it becomes harder to achieve a strategy. Basically it is Enterprise Architects message.

For the enterprise, the story starts at the set-up. Coase and Williamson stated that a firm appears when internal transactions costs are lower than Market transactions costs based on prices and contracts. At the beginning, investors use to select firms with enough strong business model to have a chance to pass the first hurdles. The following years are not out of danger. Especially, it is hard to drive growth with profitability because, at this moment, firms are loosing the qualities which made their initial success : reactivity, flexibility, agility. Suddenly hidden costs outweight profit. At this point, most of relevant keys factors concern the firm organisation which is the purpose of this post..

The point of view of game theory allows to identify the conditions which lead organisational games to an equilibrium. Y Caseau in one of its post explains that, according to organisational game models, it may exist 3 states :

• stable game which reaches a Nash equilibrium
• divergent path game called also war
• chaotic path game where an equilibrium is hard to reach

First state is usually scarce because conditions are very strong, then disruption regime is more or less regular.

The second point of view is system and information. It figures out how information moves through organisational units. Especially, Y Caseau studies meetings as information channels. It takes latency, throughput, feedback, loss and quality as indicators to figuring out how information spread across enterprise organisation.

If we consider that communication channels are natural supports to communication processes, why not extending this view to business processes, considering them as particular communication processes. Then, the next step would be to identify how business processes are connected within enterprise organisation and what would be the indicators.

Today, BPM practises bring forward methods for simulating process runs. With such a concept, same approach may be applied for enterprise organisation runs. It opens the door to conceiving new methods which will allow to validate enterprise organisation architecture.

Traditionally, firms have been observed from internal points of view, it followed a lot of papers on how culture, knowledge and faith may motion enterprises. But, with such new models, observations will be able to catch true firm behaviour and find out how, when it changes, it impacts culture, knowledge and faith. It is more or less the type of change that Hawthorne theory brought to organisational studies.

This may result in enlarging our ability to transform enterprises and business.

At a UK IT conference, a senior IBM analyst provided some clues on what IT services will become in the future which were in short :

• 70% of 2005 CIO budget was labour
• Operations labour will be 73% of CIO labour budgets by 2008
• Application development will decline at –10% CGR to 2008
• If this trend continues, there will be not development budget left by …2012!

The first one recalled me a discussion I had with a senior consultant in France who defended the view that the best IT performance indicator was staff number. By this time I was not really convinced since I expected that IT value might curb staff importance in the discussion.

If application development declines, IT value pillar may move from functions to service level. If every company is furnished with all functions it needed, differentiation will happen then on the level of service it provides to its users and to its customers.

Decreasing returns may explain decline of application development : more and more companies are equipped, for less and less, it is difficult to find new fields to applications development.

But some fields will remain, for instance, regulatory changes will always generate functions updates, event if this activity will be outsourced to software editors as companies switch to commercial software. Composite application development and maintenance will remain too. It is not really new application development but business process adaptation, for instance to a new sales channel. Anyway, no cost, no value. Then, the true question is to reconciling costs with value.

According to me, composite application platforms are the tools which may support CIO vision as a change agent.

But, if companies are not doing progress in SOA implementation, all business process changes will remain the burden of development teams which won’t tend to decrease terrifically.

The last point is competence. Even if application changes are decreasing, IT Departments need to keep enough competence to be able to maintain applications or at least to manage maintenance. This level of competence may set the floor of development costs decrease. It is especially true during holidays periods when regular users are replaced temporarily by less experienced users. A lot of errors happen then and require competent enough people to fix problems in a reasonably time.

For me, the best driver for IT department staff size is the minimum number of competences required to manage and maintain services and operations. Least is not the best, but less should not be the most. Companies need to retain enough competences to undertake and manage changes. Otherwise, they incur the risk that their IT will be managed by suppliers.

Service operations appear to be a more attractive fount of savings with centralization and automation. Microsoft, HP, Citigroup have already centralised all their worldwide computing facilities into a few data-centers. But it is only a first stage. It opens the road for drastic improvement of automated monitoring and application management. Success of such a move rely on good level of competence and good maturity level. Low labour costs with low competences lead to poor quality. Within an industrial context, good quality save costs.

This landscape may call thoughts for local implementations. If some big companies are acting as leaders, they not represent any majority. What is the suitable company size to undertake the first step of this vision ? Smaller companies will have to rely on outsourcing offerings. Countries markets agility which helps to spread such a technology and offerings is a key factor for national companies.

The same is for commercial software. Software editors are the only means for companies to implement successfully an SOA infrastructure which is the critical factor to move toward composite applications. National markets not well covered by editors may hamper companies changes.

On the other hand, as much companies are able to manage outsourced process or to perform successfully commercial software integration as better outsourcing and software offerings will be available into their country.

In the long term, winning CIOs need to take care of the service management maturity of their organisations and to pay attention to the building of their SOA platforms. They ought to challenge carefully investments in specific development because they may delay the SOA platform. They also ought to find how to demonstrate the payoff of a full-fledged SOA infrastructure (ESB, BPM, MDM,…) which does not seem to be directly linked with business. By now capital become scarce and expensive, so the job of CIO.

Companies which will remain in application development and will not be able to move to service management and change agent, won’t be able to get the savings and the returns in time, will have to struggle harshly with competitors. Those which expect, like in the past, to set a big chunk of capital to propel changes, may be disappointed by the economic outlook.

Here is, below, some thoughts I exchanged with a consultant in the Paris metro, regarding CIO life. Does it match your knowings ?

Once you have stepped in as CIO, you are facing quickly to a lot of operational concerns which usually are managed by crisis meetings. Your people expect from you to take the harsh decisions they have not been able to take and they think they need, to be backed in their day to day work. You are trying a say about strategy, everybody hears you politely, but they all seem to think : “hey, guy shed your illusions ! Here, you will deal with the hard. only if such a thought may support the budget, it is worth to have”. Your team is expecting a change but nobody believe it is still possible.

You are an experienced manager : when you made your assessment, you discovered that your predecessor did wrongly and rose significantly IT risk level. Then, you get enough resources to secure your first year achievement without undertaking too much changes. After the second year, it appears quickly that change is not so easy to make, and you not fully meet your engagements. Either your CEO is disappointed and you have to change job or, other managers appreciate that you don’t try to change too much, because it may hamper their own changes, so your CEO thinks you have done a tough job in front of adversity. You have started for a new year !

What about your team, meanwhile ? They keep doing brilliantly the operations but with great efforts. You have to negotiate each little change with them, you could not afford a slump in users satisfaction.

Because your are experienced, you ask to an IT consultancy to help your team to find transformations opportunities to make their job easier. All is tried, portfolio management, enterprise architecture, new technologies. But you are not keen to support consultancy recommendations too much because, overall, you want to keep good relationships with your team. All remain more or less in a slideware state.

Your team knows so perfectly company applications that it is very hard to be replaced without impact on the dear user satisfaction. And they don’t see why to change because they are definitely the best.

Then, you change your mind. You set an assistant next to each manager. But everybody find one just for front, and not really able to take on the job.

At last, you adopt a tactical attitude, trying to find the future managers among your people, negotiating harshly for changes. Sometimes you see an opening, and you launch a reengineering. Ouf ! May it help to solve your questions ? Not always, it needs to be successful, otherwise you may be in worse position. At least, you may find that you are playing the game …

Here is how the tough CIO life could be ! Here, no abbreviation like ERP, or SCM, and so … it is the job of the team. All lies in his capability of driving his team to the changes. According to me, it is better to take this way from the beginning instead of starting with securing his position. According to me again, the main capability lies in leadership, not in technical competence or in capability of designing good processes.

In the 80’s and the 90’s, information systems viewed the world as enterprise centric. All business facts and events the enterprise ought to manage, were entered into the system by employees or captured by technical equipements like sensors.
By these times, enterprises were compared to complex living systems made of people and machines. They need at the same times programs and psychology, that was in short the H A Simon point of view when he work out the decision process. Information systems should support all aspects of the enterprise brain, especially they should cater for a virtual machine which help to understanding events, to taking the right decision, to leading the required operations. This cannot be achieved without dealing with the question of reality representation. Beside technology, this is the main question addressed by researchers and developers.

Objects provided an efficient paradigm, widely adopted by computing industry, for building enterprise concepts representation. Because objects allow static and dynamic representation at the same time, computing systems may be viewed as logic machines catering for all technical services required for objects management.

Objects allow to hard code how parts of enterprise environment behave and how organic parts of enterprise should react, according to the enterprise understanding. The addition of the enterprise objects model with the employees knowledge constitute the enterprise intelligence , capabilities and know-how.

All these ideas are around for years.

Enterprise detects events. Some unattended, in this case an employee, a tacit worker, analyse and define how the enterprise should react. In the other cases, the rules to detect and analyse the event are codified and may performed by an internal worker.

Then, in accordance to events interpretation, enterprise start interactions with external actors which, when they are complex, may be full conversations. The following is the roll out of internal processes to fulfil external actor request, which, at last, leads to the ending conversation at the delivery and payment time. This is more or less the model developed by ANSA in the 90’s.

In 2000, when eBusiness bubble inflated, customisation was all the rage. The customer was not view as one among other concepts surrounding enterprise but like a complex system hosting processes as well.

The question of environment understanding evolves from a punctual view of interactions to an holistic one. The real question become how to synchronise customer processes with enterprise processes. This was the time of customer care and customer relationship management. But the approach remained enterprise centric, all the views were for the benefit of the enterprise or in direction of customers through the benefit of the enterprise.

Now computing industry is trying to climb an higher step. The world is no longer viewed as enterprise centric but as a whole, hosting peer-to-peer interactions between agents which may put on different roles : customers, providers, regulators, contractors, and so on.

The enterprise view universe as the location of social interactions. This is the Enterprise 2.0 era. All these, not only witnesses a mental revolution, but also a huge technological progress which sustains innovations in systems modelling and supporting agent interactions.

How the enterprise should step in this train and handle a new way of being, it is the enterprise architect very challenge!

In the life as in computing, things should remain simple. When costs of ownership exceed acquisition costs, application have to be riengineered. As this statement appears to be clear, CIOs use to keep a lot of old applications in their assets. This situation has a few causes :

• costs are usually difficult to be figured out. Years ago, Gartner designed a method to weigh the cost of a computing application called TCO (Total cost of ownership). The main difficulty comes from hidden costs which may be surprisingly high.
• If initial costs may be equally amortized, maintenance costs always change due to internal and external factors. Theory returns that maintenance costs are high when a new application is started, then decrease and increase again when applications are aging. But is it always true ?

Changes of maintenance costs result of :

• productivity improvement
• progress of tools for maintenance
• increase of salaries
• increase of application complexity due to changes

On the other hand, technology costs decrease and language progress which improve productivity in design and build of new applications, lower acquisition costs.

At last, new requirements which cannot be implemented on existing application rise costs of ownership.

If, taken globally, these factors drawn a clear picture of situation, they left locally a lot of unanswered questions.

For example, language progress has not yet overcome PACBASE efficiency which contribute to maintain such applications alive.

Costs of acquisition require as well to be contemplated carefully. Are they software and technological costs only or do they include organisational changes ? For some companies, organisational costs are very high in respect to software costs. It urges that these companies find means to lower such costs to keep their capacity of changing.

The real application life cycle, when it mixes changes and stabilisation, does not provide too much help to sort out the question. With this cycle some application are being renewed progressively. Some others are implemented progressively, then implementation costs are reported on maintenance costs. Costs are even more difficult to be figured out.

The only thing which remains thoughout the entire lifecycle is application architecture which may contribute to clarify or to blur the whole process.

It is vital for CIOs to understand and keep under control applications lifecycle because it contains some of lever arms which allow to curb IT Strategy.

First of all, implementation costs has to be distinguished from mantenance costs. Within maintenance costs, corrective maintenance costs should be identified and distinguished from evolutions costs.

Within evolution costs, evolutions costs due to regulation or law changes should be taken apart from evolutions for renewal.

Regarding evolutions for renewal, architecture extension should be carefully contemplated beside other short or straight ways. Otherwise, it may increase close down costs and consequently acquisition costs. Finally, with a global vision, we could notice that two given ways of evolution may have the same costs except that they are distributed diversely.

Having a good control on costs opens to CIOs the way to really managing their assets.

References :
Application lifecycle diagram : “Software Maintenance and Evolution: a Roadmap” K. H. Bennett V.T Rajlich

When defining IT strategy, CIO ought to balance Business Division requirements and Enterprise global strategy. Sometimes it fears strategic swings which may wipe out some of his achievements. He usually keeps at some distance Business units and CEO.

For divisional companies, IT Divisions use to deal separately with business divisions which support the cost of their own systems, and share the cost of a few shared systems. Each business division defines its own strategy and setup its requirements to IT Division regarding maintenance improvement and new projects. Then budget is approved by CFO and CEO.

CFO is at the crossing point of budget process control. He challenges separately IT budget and Business Division budgets. After this round budgets are ready to go through CEO approval.

This type of relationships are on the pattern supplier/customer.

IT Division is view as cost unit. As soon as operations are engaged, CFO come back to request how much he could get back from initial budget according real timetable. IT division is challenged on delivering value to Business Divisions : Quality of Service is not good enough , new projects are not delivered as quick as wished. IT is challenged as well on costs by CFO : why are you setting up this infrastructure ? why are you planning to train your staff on this new method ?

When business processes management orientation comes up, it usually brings with it, big CRM or SCM projects which are undergone as big reingineering. The result is a disruption into IT and Business units relationships. Then business takes the lead and shape the projects with external IT suppliers which appear more reliable and more competent than internal IT.

It is urgent that IT Divisions target to exit from this position and develop a true partnership with Business Divisions. Therefore, it requires big changes in processes, in competences and in mindings.

From my point of view the first point is costs transparency. Business Divisions need to understand, besides the gains they get from IT, the costs they bear. Some CIO fear costs transparency because CFO and Business may find arguments to harden budget challenging. Benchmarks with external integrators costs may also get the things worse. But, when you consider that IT Divisions main goal is to manage the rolling out of the company IT Strategy for several years, it is much different than what external integrator companies aims to, which is to provide optimal cost for given operational services. Investments in IT Divisions, help them to better support company business and also to improve their own processes which will make them better to performing their first purpose. A kind of virtuous circle !

The second point is projects timely delivered. Time to market is a fundamental requirement from Business. Usually, this point is adressed by reviewing project execution performances and pointing out IT Division weaknesses. Removing weaknesses should not be taken as a change prerequisite, but been carry on in parallel with IT and IS infrastructure improvements. IT modernisation is not only matters of practice and competences, but as well matters of technical environments. What will be automotive plants performances without robots ? This point brings back again to strategy capabilities of IT Divisions.

When IT Divisions succeed in undertaking such changes, they may develop a true partnership with business and change their position regarding CFO and CEO.

Last Thursday, I attended to a Marcus Evans conference in Paris on Enterprise Architecture. For those who are not familiar with, Marcus Evans is definitely not a new pub name, but a very serious organisation in the conferences business. Once a year, they use to cover the topic of Enterprise Architecture local ongoings which attracts more or less the same actors, attendees and speakers.
I like it, because most of the time, people present their feedbacks : successes, drawbacks and outcomes. I am always impressed because project managers used to be very talented when they talk about their projects. This time the purpose was : “Enterprise Architecture, 7 years after”.

Since 1996, France settled the practice of “Urbanisme” based on City Organisation paradigm which is fairly closed to Enterprise architecture.The principles are to group information functionalities according to the type of resources they require. For instance, operational functions require transaction oriented resources with high availability, while external exchange functions require resources for managing and securing exchanges with actors located outside Information system.

When SOA appeared, “Urbanisme” dodged the new questions it brougth forward : for instance how to identify the services ? how to identify service operations ? These were among the subjects addressed by the conference speakers.

The first, Michel Brouant, Architecture Manager at Unédic, presented the roadmap of the Unedic and Assedic systems merging. The timetable was impressive : four months for setting up the roadmap due to few systems overlaps except for support processes like human resources, accounting and so on… three years of duration.

The roadmap combined 3 types of projects : Accessing IS (agent, customer, partners), streamlining systems, business functions like master data…

In a context with a lot of organisational questions left, the success came from a mature team which already had tools like systems maps and inventories. These helps to boost as is assessment.

Rafaël Gutierrez, Project Manager at Environment State department, presented the implementation of a generic Business Process Management engine. The approach of rolling out quickly such a service and connecting systems after, allows to start quickly with simple projects and skip more easily to more complex projects.

Nicolas Bogucki, Chief Architect at INA, presented the tool out of a tool which automate some parts systems mapping. It helps as well as functional and business mapping. The project choose Telelogic System Architect because it allows to customise metamodel and support automation like VBA.

Christophe Rémy-Neris, Editing Domain Director at Canal Plus, presented the benefits of SOA for a migration projects.

Stephan Chraibi, IT Strategy and Architecture Director at Aviva, presented a global project which allow to rearrange and group systems using virtualization technology.

Then François Rougier, CIO at MACIF, presented a system architecture evolution project toward multichannel customers relationship management. His model spans 4 layers = business systems which provide basic services, business procedures which orchestrate services, system procedures specific to a channel and human interface. He seeks the target of maximising service reuse, since his cost model shows that return on investment increase as services are reused. His main issue was to manage changes of services .

The last speaker has been Olivier Guerin, Director of “Urbanisation and SOA Strategy” at Dreamsoft. He developed the point of view that “Urbanisme” practise and SOA are tightly linked. He draw the prospect that “Urbanisme” helps to succeed in SOA.

The day finished with a round table on more feedbacks regarding SOA projects.

The conference presenter was Claude Durand, Strategy Director at Osiatis. He fare well in introducing and concluding briefly each presentation and in boosting questions and answers sessions.

The lesson of this day may be to demonstrate that the steps to SOA don’t always start with business transformation projects. It requires also a maturity level of technical infrastructure. Projects which contribute to improve technical architecture, may be a lever for the SOA roadmap. However even such projects need to be supported by a strong business case.

Two weeks ago, while exchanging views on business with a CIO of a medium sized enterprise, he put the question of IT architecture governement on the table. What benefit could he expect by setting up a new process, consuming resources and budget ? Is it really necessary when the project backlog overwhelms his IT teams ? For sure, architects are useful within projects, but keeping them outside with the result of adding burden to project plans is not an attractive option. He set his first priority not to be Cobit or ITIL compliant, but to be really aligned with enterprise business.
As an experienced consultant, I was thrilling about throwing out good practice for a short term view. But, was my speaker right after all ?
For him, the value of governing architecture depends on what the enterprise is able to obtain in return. Indeed, when IT Division is scattered into application teams which manage change within their domain, settling transverse processes may appears to increase dependencies and risks.

According to the enterprise information system maturity, there is an appropriate level of architecture governance.

Level one
Medium sized enterprise with Commercial off the shelves for accounting, payroll, sales and production management. Several sales points and production plants. Each department focus on its own process, and exchange files with others when necessary.
Focus : Technical architecture for streamlining hardware use and purchase

Level two
The same medium sized entreprise which would like to tie its COTS with middleware like a Message Oriented Middleware or an automated file transfer for improving back-office and statistics. Each department would like to have feedback on its performance more quickly.
Focus : application architecture for enabling exchange capabilities

Level three
The same medium sized enterprise which would like to supervise customers from sales to delivery across points of sales and production plants. For example with business intelligence capabilities.
Focus : information architecture for sharing information meaning across different COTS

Level four
The same medium sized enterprise which would like to run business as processes
Focus : Business architecture for supporting, improving and automating business processes

Often, during their history, companies go through each of these levels. Skipping to next level requires to improve IT and IS management skills. Jumping 2 levels requires a true transformation of IT processes. Frequently blue chips are at level four and have mature IT governance processes, but paying attention to SME information system maturity allows to identify the appropriate level of Architecture governance and being successful in setting it up.

As Enterprise Architecture buzz is gaining ground within IT Divisions, what auditors, may think about it ? Since version 4.0, one of Cobit focuses is strategic alignment which is attained by a 3 stages macro process : translating by the business into objectives related to IT-enabled initiatives, defining IT’s own objectives, defining the IT resources and capabilities required to successfully execute IT’s part of the enterprise’s strategy. Although the CIO is responsible for the whole process, the IT Chief architect contributes to stage 1 and stage 2, and is responsible for IT architecture design.

With ITIL, the situation is much more confusing. In its post “ITIL v3, Enterprise architecture…“, Steve Thorn who made a research on TOGAF 8.1.1 and ITIL v2 relationships for the Open Group, points out that service strategy process is not very clear about Enterprise Architect responsibility alongside project portfolio manager and IT service manager responsibilities. Enterprise Architect role may be shared by both of them.

TOGAF 8.1.1 addresses strategic alignment as well, but focus on Architecture life cycle. It gives the responsibility of identifying business requirements and designing IT architecture to IT architects, up to them to identify stakeholders and to set up the detailed process.

According to Cobit Togaf 8.1 mapping document, Cobit and TOGAF cover more or less the same extent regarding entreprise architecture. They may be considered as complementary in respect of TOGAF is adressing detailed activities of Cobit Chief Architect.

With Cobit, auditors find support to assess architecture macro process regarding deliverables and performance through KPI assessment. But, as design decisions are critical, it is interesting to detect flaws earlier than system go in live time. Because TOGAF is compatible with setting up a Quality Insurance Activity dedicated to Enterprise Architecture, it is a very interesting reference for managers and auditors.

Nevertheless, in accordance with framework approach, process are loosely defined, each company has to decide of its own implementation. Then, auditing Enterprise Architecture requires for the auditor to be able to assess not only if the process implementation is appropriate to company goals, but the same about methods and if indicators enable to detect quality risks early.

When Cobit enables to manage and drive globally strategic alignment, TOGAF, although restricted to architecture function, may be used equally on the scope of a whole company, a business domain or a program. With TOGAF, IT Divisions are able to manage alignment locally and globally at design time. Often Business Divisions focus on time to market and time-scale, when companies mainly focus on compliance and costs. TOGAF allows to build a comprehensive framework which may drive all design activities of the IT Division in accordance with Business Goals.