Test Blog

Capability Architecture: A new paradigm or new packaging?

No Comments »
March 25th, 2010 Posted in Leadership, Theory, Trends

  

Capability thinking is nowadays catching the attention of the trend watchers such as Gartner and Forrester. However, Capability thinking is an old idea which mainly has been used within strategic management and military domains. This idea is making its way to other domains including architecture. So, how does this idea translate to the discipline of Enterprise Architecture (EA). This is one of the research topics we are working on within our enterprise architecture unit. In this blog I will give it a try to put some ideas together and I will be happy to see your ideas and feedback on this topic.

A capability is the capacity to deliver value by using a set of resources

 

There are of course many perspectives to look at capability architecture (thanks to my colleague Frank Schalkwijk with whom I’ve been lately involved in insightful discussion on this subject). In this blog I will rather address the business perspective.

But just to avoid the most common trap of a solution push ;-) , let’s first see if there are any problem areas we can address with capability architecture. Capability architecture is by the way not an alternative for EA. It is rather one of the many perspectives on EA, but in my view a valuable and refreshing one.

 

Back to the problem areas, we see and most of us have been involved in or a witness of many disconnected solutions and technology implementations… what a waste! One of the many reasons for this is that many of the promising concepts and technologies have been used and implemented in isolation resulting in silo solutions, which don’t deliver their full potential in organizations.  Examples of these concepts and technologies are: SOA, BPM, Cloud, just to mention a few of them. Additional to the solution and implementation problems we also perceive communication problems regarding communicating with and involving business people and mangers in the architecture journey.

 

I believe the potential of technology and other resources would have been of much bigger impact and value, from a capability-push point of view, when the capabilities of these technologies and other resources are deployed to serve the core business functions of organizations and not for the sake of technology itself. The core business functions, from the business perspective, matters the most as they are directly connected to the business objectives. These core business functions are usually named ‘business capabilities’ in the literature. But I think we all agree that the business functions on their own without support and endorsement of the necessary resources (people, technologies, etc.) won’t deliver any value on their own. This idea brings us to capability architecture, which is the foundation that links the different capabilities together in a consistent way in order to deliver business value. One of the governing principles therein is the separation of concerns, which comes down to the separation between the ‘what’ and the ‘how’ of the foundation. From the business architecture perspective, the focus should lay on the “what”, which identifies the most stable capabilities within organizations. These capabilities are the business capabilities as they are directly related to the business objectives.

 

Business capabilities are an abstract view of what business functions do. They define the “what’ of the business functions and they are not concerned with organization en implementation issues, the “how” perspective. Business capabilities have attributes such as business value and performance. These attributes help assess their added-value and identify the change area that should be addressed. Business capabilities are also more stable than organization structures, processes, technologies and other resources. Their ‘relative’ stable nature makes them most suitable for building future-proof architectures.

 

As mentioned previously, this is just one of the perspectives on building sound and result driven architectures, but in my view a very determinant one for staying business-focused and delivering business value. Governance mechanisms such as standardization, coordination and the-how-related aspects deserve, of course, equal attention as well.

 

In conclusion a few benefits of capability architecture: in my view, the relative stable nature of business capabilities within organizations offers a shared abstract view and a common language, which fosters communication and closes the gap between architects and business people. As a result both parties have the same view of the problems at hand, less frustration, trust between both parties, and a better starting position to deliver greater results (the bottom line). Additionally, the abstract view on the business functions provides a suitable mean to define and scope services and lead to a service oriented architecture, which implement the capabilities.

 

Capability architecture should align/integrate the available capabilities toward generating value for the business. And that’s what architecture should focus on.

 

So, what do you think? Is the idea of capability architecture a new paradigm or a new packaging?

 

Ahmed Ibouhouten

EA as a service

No Comments »
February 2nd, 2010 Posted in Alignment, General, Governance, Knowledge and Craftmanship, Leadership

 

Elke Enterprise Architect die zijn vak ook maar een beetje serieus neemt, heeft zichzelf ooit de vraag gesteld, welke architectuurservices lever ik aan mijn klanten/opdrachtgevers? Dezelfde vraag geldt nog in sterke mate voor een architectuurteam of unit. Een architectuurteam staat nl. bij uitstek opgesteld om architectuurservices te leveren aan zowel de business als IT. De verantwoordelijkheid voor de opgeleverde services ligt ook bij het team en niet bij de individuele architecten.

 

Wat mij opvalt in sommige organisaties is dat het niet altijd helder is waar een architectuur-team voor staat en welke services vallen onder haar verantwoordelijkheid voor zover er überhaupt een definitie is van een serviceportfolio. Het grootste gevaar hiervan is dat je twee uitersten in de praktijk krijgt. Het eerste uiterste is de autoritaire stijl waar niets-mag-alles-moet. In dit uiterste wordt strak gedacht en gehandeld vanuit de toepassing van de wet (referentie architectuur) met weinig oog voor de dynamiek en de cultuur van de organisatie. In het tweede uiterste krijgt de laissez-faire stijl de overhand. Het roer wordt hier overgelaten aan de capabilities van de individuele architecten. Het effect van dit laatste is verwarring bij de klant (business en IT) door gebrek aan een geconsolideerde en eenduidige boodschap. In mijn beleving leveren geen van beide uitersten het gewenste rendement en daardoor blijft architectuur in de ogen van de business maar onvoldoende uit de verf komen.

 

Bij gedrag en houding van een zakelijke dienstverlening hoort ook een serviceportfolio waarmee je doelgroepen wilt bedienen. Met een architectuur serviceportfolio wordt voor de architecten duidelijk wat ze moeten leveren, aan wie en in welke context. Voor de business en IT wordt ook duidelijk op welke ondersteuning ze kunnen rekenen. Dit komt de zichtbaarheid en verantwoordelijkheid van een architectuurteam ten goede. Anders is een architectuurteam afhankelijk van de individuele capabilities van haar architecten. Natuurlijk dragen de individuele capabilities bij aan een goed functionerend team, maar de verantwoordelijkheid voor de services mag daar niet van afhangen. De capabilities van een team zijn meer dan de som der individuele capabilities. Een serviceportfolio is ook de leidraad voor het bepalen van de capabilities van het team en die van de individuele architecten uiteindelijk.

 

De samenstelling van een serviceportfolio is uiteraard afhankelijk van de context waarin een architectuurteam actief is. Gebaseerd op mijn ervaring kom ik tot de volgende taxonomie van architectuur services:

 

» Impact services: gevolgen van wijzigingen in kaart brengen en daarmee inzicht verschaffen m.b.t. investeringen;

» Portfoliomanagement services: ondersteuning bij afbakening van projecten, samenvoeging van projecten, prioriteiten stellen en bepalen van afhankelijkheden;

» TCO services: hefbomen van bestaande oplossingen (infrastructuur en applicaties) door o.a. hergebruik en gebruik van standaarden;

» Kwaliteitsborging services: uitvoeren van reviews en assessments van architectuur- en ontwerpproducten en plannen van aanpak

» Advies services: dit varieert van adhoc beantwoorden van vragen tot het leveren van adviezen aan projectmanagers, programmamanagers, consultants en directie;

» Kaderstellende services: definiëren van referentie architecturen (principes, referentiemodellen, etc.)

» Strategie services: creatie van doelarchitecturen en bijbehorende roadmaps;

» Research services: Ontwikkelen van nieuwe instrumenten en methodieken, technologie trends, etc.

 

Beste lezer,

Heb je een andere mening en/of een andere taxonomie van services… please share!

 

Ahmed Ibouhouten

Introducing Enterprise Architecture 2.0

No Comments »
October 30th, 2009 Posted in General, Knowledge and Craftmanship

Since my last blogpost, I have reflected way too long on the question/thought I had regarding the ‘difference’ of entrepreneural business I am involved in ‘versus’ enterprise architecture, sorry for that.

Nevertheless, here is my first view: a potential difference lies in the ambition of architecture. Introducing ‘EA 2.0′ could emphasise the accent needed to become more entrepreneurial.
How?

Architecture is (just) now ‘shaking off’ the burden of craftsmenship (with many ambigue and ‘magical’ moments) and is moving forward towards a more objective capability, via well documented methods, certification programmes and a ‘body of knowledge’ to guard and guide the profession. In practice, architecture still mostly is being executed as a means of structuring the system for maximum meeting/enabling of the business requirements.

If this is really true, low quality business requirements result in low quality architecture, and, no business requirements in no architecture? Garbage in = garbage out?

No, not true, given an objective of a company, dynamics in IT and an installed base, the anchor points for architecture are already there, regardless the presence or quality of current requirements. Basically, a good architecture allows the owners of a system to harvest long and short term objectives. This positioning of architecture therefore goes beyond ‘the architecture’ per sé, it is about installing and leveraging a capability to cope with change and any requirement.

If this is true, than architecture should abstract from the content of the design in any particular (requirements-) case, but should focus on installing a capability into an organisation, and immediately put it into action to resolve the (design) case at hand.
So, just ‘following’ the business requirements with enabling architectures is the minimum contribution that may be expected. From the view of an architect, it will mostly not feel like entrepreneurship, it’s getting the guidelines for the system done.

Now, the emphasis on entrepreneurial aspect of architecture (EA 2.0) lies in the attitude towards requirements and momentum of the execution. The more architecture is ahead of, and anticipatingon business change, the more it ‘feels like’ making a difference when you’re an architect.

That results in working on and in architecture which has existance and contribution without the business…….to good to be true?

What if we’d install a ‘learning loop’ into practice and improve our architecture performance and fundamental assumptions each time we practice it. And, I do not mean the classical ‘circle’ of TOGAF, but I mean the ‘double loop learning’ as depicted in reference. Also good reading is Argyris, C. (1977), “Double-loop learning in organizations”, Harvard Business Review, pp.115-24.
(diagram source: www.learning-org.com)

So, not just ‘document knowledge and try again’ when delivering architecture, but ask oursleves the question whether we ‘do’ architecture in such a way that we can create the desired impact and increase the capability. So, not only evaluate ‘the’architecture, but evaluate ‘architecture’ as a whole…..and even decide to NOT do it next time ;-)

 

Is that entrepreneurial enough? Yes, it is EA 2.0 !!
The 2.0 refers to the double loop learning aspect.

Aligning through Roadmapping – The Process Perspective

No Comments »
October 23rd, 2009 Posted in Alignment

Aligning organizations needs sound Roadmaps. Roadmapping as the process of producing roadmaps is a powerful and flexible approach covering usage areas that varies from strategies to operations. Understanding and organizing the roadmapping process is therefore critical to build workable roadmaps. In my previous blog I have defined the term ‘Roadmap’ and also provided a basic roadmap framework. In this blog I will elaborate on the process that builds roadmaps. The process involves three main activities: a preliminary preparation, a development activity, and a follow-up activity.

 

Preliminary preparation

Before proceeding with the development of the roadmap, some preparation should be done first. The emphasis during the preparation should be put on satisfying the critical conditions that validate the need for the development of the roadmap. The key criteria to consider when planning a roadmapping activity are:

 

Context:

The topic or issue that is subject to roadmapping, needs some exploration with regard to the following:

Roadmapping is a collaborative process. Therefore, the need for a collaborative process should be validated, the involvement of key stakeholders and the availability of needed skills and knowledge from different functional domains is ensured, resources are allocated (budget, time, and facilitation), the business ownership is established and the scope of the effort is defined. In the scope the specifications of the boundaries and objectives of the effort should be clear and well articulated.

 

Process

The process should be needs-driven rather than solution-driven as there might be more appropriate solutions for a need. Depending on the amount of people involved and the toughness of the subject, the appropriate approach should be used to execute the process. One can choose between the expert-based approach and the workshop-based approach.

 

» Expert-based: A team of expert (e.g. technical and business people) comes together to develop strategy/ambition, identify needs, solutions, technologies, resources, risks, etc. and relationships that link these dimensions together

» Workshop-based: This approach is aimed to achieve the same results as expert-based approach. Additionally, this technique is used to engage a group of stakeholders and surrogate users to achieve better understanding, and build consensus

 

The workshop-based approach is recommended when consensus building is at stake. Moreover, the ‘hands-on’ nature of the workshop-based approach makes the group responsible for building a shared visual representation of the roadmap. Another key advantage of this approach is the communication that takes place during the workshop.

 

The process can be supported using facilitation techniques and a facilitator can be engaged to facilitate the development of the roadmap.

 

Structure

Structure refers to the number of the perspectives that are involved to build the roadmap. Perspectives make part of the structure of the roadmap framework (see my previous blog). Generally three perspectives are used: Needs/Purpose, Delivery, and Resources. The number of perspectives is customizable depending on the business context and the subject at hand.

 

The following figure depicts the iterative nature of the Roadmapping process and the criteria to consider in the preparation phase.

 

Source: Adapted from Robert Phaal, University of Cambridge

 

Development of the Roadmap

 

Once the preliminary preparation has been completed, the development of the roadmap can then take place. The steps that will be required to build the roadmap will be different for each organization (and even within organizations). The organization of the process depends in great deal on the context (see above). In case the workshop-based approach has been adopted, a series of workshops can be held. The number of workshops will depend on the number of the perspectives that have been adopted. One workshop per perspective is the rule of thumb. However, the business context can lead to a different choice. A final workshop brings the different perspectives together on a time basis resulting in a first cut roadmap. Linking perspectives involves consideration of assumptions, options, constraints, gaps, and risks.

 

 

 

Follow-up Activities

 

The development of the roadmap results in producing the roadmap report. The report consists of a graphical representation putting the total picture together. Textual explanation can be provided. The challenge in this phase is keeping the roadmap alive. The added-value of roadmapping is ensured only when the information that is captured in the roadmap is current and kept up-to-date with changes that take place along the way. Therefore, the ownership of the roadmap should be established. This ownership is responsible for updating and communicating the changes.

 

 

Conclusion

 

Roadmapping is an approach that offers a great ‘hands-on’ opportunity for Enterprise Architect to make change happen within organizations. Developing roadmaps is one of the competences Enterprise Architects (must) have. Unfortunately, the current Enterprise Architecture methods lack content on how to build roadmaps. This has been one of the reasons why I’ve been interested in finding out more about this topic. In writing these blogs I’ve been supported by the literature on Technology Roadmapping which has been a great inspiration for me. Below I have provided a list of literature on this topic for those who want to use this blog as appetizer.

 

Ahmed Ibouhouten

 

Further reading:

 

» Richard E. Albright. A Unifying Architecture for Roadmaps Frames a Value Scorecard. Albright Strategy Group: http://www.albrightstrategy.com/papers/Albright-IEMC2003.pdf

 

» Thomas A. Kappel. Perspectives on roadmaps: how organizations talk about the future. Elsevier, 2001

 

» Robert Phaal, Clare Farrukh and David Probert. Technology Roadmapping: linking technology resources to business objectives. Centre for Technology Management, University of Cambridge, 2001

Can Enterprise Architecture suffer from cultural bias?

No Comments »
July 22nd, 2009 Posted in Enterprise Architecture

A few weeks ago I was on holiday in Austria. The village where I stayed was so small that the house number was sufficient to identify a unique address. The streets do have names, but the house numbers are unique within the village! (if you want to, check out the village plan – the house numbers are all over the place)
 

For some reason this had never occurred to me, but it seems pretty obvious when you think about it. Presumably there are places in darkest Africa or Outer Mongolia where even the house numbers aren’t needed.
 

Back at the office I thought I’d check out how one ERP system (SAP) handles this. SAP has done quite a good job in accommodating international addresses, but when I tried to create a new customer the street name was compulsory.
 

Google then took me to some fascinating stuff about address modelling in GIS systems. Complex models covered many possibilities but as far as I could see every address had a street included.
 

Clearly I had made an assumption about what constitutes an address based on my background and experience. You could argue that this is a foolish error and that you should always question any assumptions. However, as you can easily verify for yourself, many people have made the same assumption. If the assumption is so ingrained in your thinking that you don’t see a need to question it, then it’s a form of cultural bias. Doubtless the software developers in that Outer Mongolian village would have designed a different, though not necessarily better, solution.
 

This then set me wondering about whether there is a cultural bias in Enterprise Architecture. For example principles certainly can reflect cultural norms – we’re unlikely to find anything relating to the Divine Right of Kings these days. But I can also imagine that the way that we design processes and model data can be subtly affected.
 

In fact I’m certain that there is cultural bias in EA. Just look at the difference in approach between private companies and government bodies. Since an architecture and the architects have to operate within the confines of a particular culture, this is not necessarily a bad idea.
 

However, can cultural bias have a harmful effect on EA? Could it lead to poorer solutions? And how do we, as architects, avoid this? I shall certainly be paying attention to this in the future! 

Architecture…take a break

No Comments »
July 9th, 2009 Posted in Enterprise Architecture

Recently, I have been involved in setting up a ‘mobile’ solution group. Great people, fantastic market potential. This is about entrepreneurship, change change, being first, being clever, being pragmatic.
Alongside of that, I have continued to manage and drive architecture, of course. And, I have done some assignments and reviews on architecture projects.

Some observations have struck me, hoewever. Things I will be contemplating during my holidays.

Doing architecture still feels like a craft, rather than a well defined capability, nevertheless, the role itself always is prominent in organisations. That in itself is not problem, but hey, how effective is architecture?
Setting up mobile is also a craft, but it pays off!!

When discussing architecture choices or directions, there is constant switching from approach/method to contents when discussions become ‘sharpened’. It’s like we blame the method, or we ‘hide’ in methodological language; why not just say ‘sorry, wrong’ then we can quickly restart.
Mobile is a lot of trail and error, feels like innovating, not methodologising (is that a word? ;-) ) which is close to apologising, haha.

I feel the need for the next step towards a mpre mature architecture profession, with capable content knowledge-workers, not method-executors.

I’ll inform you about the holidays-findings in my next blog.

Practical research content on Enterprise Architecture and Tr

No Comments »
June 16th, 2009 Posted in Enterprise Architecture

 

Practical research content on Enterprise Architecture and Transformation

Donderdag 11 juni heeft de eerste conferentie plaatsgevonden van PRET. PRET staat voor Practice driven Research on Enterprise Transformation. Dit jaar maakte PRET onderdeel uit van de internationale CAISE (International Conference on Advanced Information Systems) conferentie die voor de 21e keer gehouden werd in Nederland, zie http://caise09.thenetworkinstitute.eu. PRET verzorgde het industrial event binnen deze academische conferentie. De bedoeling daarbij is bruggen te slaan tussen de wetenschappelijke wereld en de IT industrie. Als zodanig maakt PRET als NAF Academy http://www.naf.nl/nl/naf_academy/ ook onderdeel uit van de Nederlandse Architectuur Forum (NAF), die bekent staat als initiator van het jaarlijkse Landelijke Architectuur Congres (LAC), zie http://www.naf.nl/nl/lac/lac_2009.html.

Tijdens PRET werden aan de hand van papers een tweetal discussiesessies georganiseerd, waarvan één door mij werd geleid. Het wetenschappelijke onderzoek werd daarbij getoetst aan praktische toepasbaarheid. Inzichten rondom thema’s als Business Process Management, Solution Architecturen, Enterprise Architectuur functies, Strategy Elaboration, Outsourcing, Governance in relatie tot Enterprise Transformatie, passeerden de revue. Allemaal waardevolle content die instrumenteel ingezet kan worden binnen projecten met klanten. De papers zijn terug te vinden in het boek dat hiervoor is uitgegeven bij Springer.

Ik was ook gecharmeerd van het onderzoek rondom Process Mining, uitgevoerd door de technische universiteit van Eindhoven (http://prom.win.tue.nl/research/wiki/), dat in de ochtend aan de orde was gekomen. Uit real-life loggings van processen worden processen gegenereerd waarop direct en met een soort van simulatie tooling analyses op plaats kunnen vinden. Procesaanpassingen kunnen hiermee met een snelle ‘Return on Archtecture’ worden terugverdiend.

Al met al een geslaagde dag, waarbij Atos Origin Nederland ook haar wetenschappelijke aansluiting heeft kunnen laten zien.

Frank Schalkwijk

 

 

 

Achieving Alignment through Roadmapping

No Comments »
June 15th, 2009 Posted in Alignment

In one of my previous blogs I have written a little article on Agile Alignment (in Dutch :-( ) and I have promised the reader to get back on this topic with more insights. In that blog I have stated that achieving alignment is easier said than done! … not only the literature comes to this conclusion, but the daily practice has shown this too! On the other hand, there are many frameworks out there that address the topic (Tapscot, Henderson & Venkatraman, Luftman, and others), but very little on how to achieve it. Among the reasons why alignment is difficult to achieve is because it involves many dimensions to look at in a continuously changing business environment. Another important reason is that it is not a one time effort. Alignment is a continuous endeavor to keep the enterprise assets aligned with the business objectives. Such endeavor needs a manageable lightweight instrument. Roadmapping is a such instrument that, when used adequately, should benefit alignment and hence the bottom line.

 

Roadmaps are traditionally used by travelers to decide among alternatives routes toward a destination. It is an instrument used by travelers to gain understanding, direction, and some degree of certainty in travel planning. From the perspective of Enterprise Architecture, roadmaps are used for architecture landscape transformations, innovations and business development in general. Many of us have been through the exercise of putting a roadmap together, be it in isolation or in collaboration with others. In both ways many of those roadmaps are seldom successfully put in action. There are many sources of unsuccessful and sometimes even bad roadmaps. A well known example of bad roadmaps is the ‘Roadmap for Peace’ in the Middle East. One of the major reasons why it is failing is because it has been lacking involvement of the concerned parties and consequently lacking commitment to put it in action. Well, that’s ‘Global Architecture’ ;-) and not Enterprise Architecture, but it brings clearly one of the most important ingredients of failing roadmaps to the table. The following list identifies some additional failure factors:

 

» Lack of a common and unified process to roll-out roadmaps

» Roadmaps are created in isolation

» Lack of commitment and buy-in of involved parties

» Poor functional, technical, and business input

» Wrong roadmaps for a path to move forward

» Silos thinking and execution

» No Visible logic

 
Source: http://www.dcpalestine.com/

So, wat we actually need is an instrument to produce good roadmaps! And by good roadmaps, I mean workable and result-driven roadmaps. The answer lies in the process; the Roadmapping process.

Roadmapping?

The term Roadmap has gained popularity and is used as a metaphor for planning. Roadmapping, on the other hand is the process of roadmap development. It is a collaboration process of capturing information and knowledge for the purpose of making better decisions and selecting the best fit solutions to move forward. Collaboration from the process perspective is about organizing the group’s communication, the group’s coordination as well as the group’s cooperation through sharing information, resources, and providing support to one another. It is also a process where parties involved see different aspect of a problem and contribute to alternative solutions from their own views and expertise.

Furthermore, roadmapping should not be confused with scenario planning where the focus is on forecast. Roadmapping, instead, starts with an end-point or a vision and it then works backwards using a backcasting approach to trace the alternative paths to achieve that vision or some defined objective.

 

 

The Roadmapping approach is based on a simple framework that aims to answer a set of three basic questions, see below.

» Why, this is the business/market level; defines the objectives, needs and drivers

 
Roadmapping Framewrok
Adapted from source: Albrigt strategy

» What, defines the products and services that satisfy the defined objectives and needs

» How, defines the technologies, resources, skills that are needed to make a successful implementation

» The forth part defines the action plan (the to-do’s ). The action plan defines the key development actions. All parts of the roadmap are laid out over time. The ‘When‘ of the roadmap. The result of this forth part is a project portfolio.

Answers to these questions are further linked through a capability push and a business pull mechanisms.

 

The roadmapping approach has it’s roots in the technology and product oriented industries such as the semiconductor industry, but its flexibility offers support to a broader range of business aims. The framework offers a multi-layers structure. Each layer may include sub-layers. This flexible structure offers the possibility to include all the dimensions that might be judged relevant for the problem or topic at hand. However, the framework, no matter how good it is, won’t do the job on its own. Roadmapping is much more about the process of defining the structure, building the roadmap and continuously updating the roadmap.

 

In my next blog, I will further elaborate on the roadmapping process.

 

Ahmed Ibouhouten

Architectuur is bestendigen, niet veranderen

No Comments »
May 28th, 2009 Posted in Enterprise Architecture

De moeilijkheid van architectuur is, dat je iets voor de lange termijn wil realiseren; een visie, een doel. Dat gaan we doen door initiatieven die NU plaatsvinden te ‘begeleiden’ of te ‘richten’. Dat valt niet mee, is de visie wel waar of reël, laat staan dat de begeleidende rol van architectuur valt te meten (dat wordt trouwens wat als dat wel kan). Maar goed, mijn pleidooi gaat over de zin en onzin van uitgebreid architectuur ‘doen’ met als verwachting/geloof/hoop (kies maar) dat het dan in de toekomst leidt tot een goed (IT) landschap. Goed betekent: bruikbaar, aanpasbaar, betaalbaar, uitbreidbaar en weet-ik-veel-baar. In veel gevallen is architectuur achteraf gezien een grotendeels hachelijke zaak geweest.
Mijn advies (geïnspireerd door Jan Truijens): richt je op dat was BLIJVEN moet en niet op wat VERANDEREN gaat.

In plaats van verandering te gaan begeleiden door visies concreet te maken en proberen implementeerbaar te maken, richt je op wat je wil dat NIET veranderen mag.
Bepaal daarna wat op dit moment nog wel heterogeen is, maar eigenlijk ook geschaard moet worden onder de gestandaardiseerde ‘blijvertjes’.
Het mooie is, dat ‘datgene wat blijft’ zich gedraagt als ware het infrastructuur. Dit is herkenbaar aan de centrale governance, de gezamenlijke financiering van onderhoud van de faciliteit, de individuele afrekening per gebruik van de faciliteit, de strak ge-coordineerde distributie etc.
En oja, de STANDAARD waarop/waarmee iedereen MOET werken. Alles wat ‘daarna’ gebeurt is heel flexibel, want heterogeen geïmplementeerd.

Ga als architect nou steeds meer van de heterogene zaken van het heden proberen onder de uniforme standaard infrastructuur te brengen. Laat al die heterogeniteit op zich maar gaan, hopeloos om dat allemaal te willen ‘richten’ met architectuur.

Dit heeft twee voordelen:
- je hoeft niet met de business workshops te gaan hebben en interviews te gaan doen en allemaal ambigue resultaten proberen tot chocola te maken (iets wat dan achteraf weer verkeerd begrepen blijkt)
- je bouwt voort op de kracht van de huidige infrastructuur (let op, dit is dus meer dan alleen hardware en applicatie-/integratieplatformen)

Het heeft ook twee nadelen:
- het voelt minder ‘sexy’ dan hemelbestormende visie-naar-architectuur trajecten
- het is veel moeilijker dan het lijkt, want hier maak je de ‘echte’ keuzes, namelijk dat wat blijft……..en zichtbaar is….enafrekenbaar gemaakt wordt……

“door alle verandering heen, is het de constante die waarde bezit”
(klinkt als een bekende quote, maar ik weet niet van wie, indien van niemand, dan bij deze van mij ;-) )

Richard

Where’s my Canonical Data Model?

No Comments »
May 12th, 2009 Posted in Modeling

I think it was last year that Jan Baan spoke to the assembled Atos Origin Enterprise Architects. At one point he said “Data is still the king” which for some reason I found rather comforting. How does an architecture work if data isn’t managed properly?

In the brave new world of SOA the term canonical data model appears. Canonical is yet another word that’s been borrowed by the IT world and then used in an imprecise fashion. In mathematics the term has a precise and formal definition (see Wolfram’s Mathworld if you’re into that sort of thing) and something that is canonical is universally applicable – well, at least in the world of mathematics. Of course canonical data models aren’t, so I can’t buy one just yet. 

Concept

Let’s quickly (and imprecisely) review what a canonical data model is. The basic idea is that we need a means of passing data between our loosely-coupled applications. Of course these applications can store their data in different ways and to avoid the necessity of point-to-point conversions we introduce the canonical (common) data model. Now you can transform the data from source application 1 to canonical format and then transform from canonical format to the format required by target application 2.

 Canonical Data Model

This idea is not new. The concept first emerged into public prominence, under the name conceptual schema, with the publication of the ANSI / SPARC Database Model in 1977! The ANSI three-schema architecture was not extensively implemented at the time but currently the idea has re-emerged in the SOA context. By the way, there’s an interesting description of the concept of a canonical data model in Jack van Hoof’s blog which despite its title doesn’t address the semantic issues. 

Issues

So what’s my gripe? My first point is that a canonical data model obviously isn’t universal. The common data model of everything hasn’t been built yet and when it is it will probably turn out to be the 42 from the Hitchhiker’s Guide to the Galaxy. What then is the scope of the model? Is it a model of data objects for generic subject areas, for a specific company, or maybe industry-wide? Will my canonical data model look like your canonical data model and will it matter if it doesn’t? Typically the approach seems to be the creation of a model for your enterprise (on the inside looking out) where I guess “enterprise” would be business group for some large corporations. What also happens is that external standards are incorporated in the model (for example Dunn & Bradstreet numbers for customers/suppliers or UNSPSC for product classification). It’s not obvious to me what exactly to build into the model – it’s not a trivial problem. I also get the impression that many architects see the model building as a straightforward analytic exercise whereas some people in the data management world see data modelling as a creative design activity. How am I going to arrive at my canonical data model and how will I maintain it?

My second issue is that having a canonical data model doesn’t really address the semantic issues. For example what happens if you want to exchange information about customers between two systems? The canonical model maps data structures and not individual data values so how will you know that customer A in system 1 is customer 123 in system 2? It looks like we need some agreement about a common identifier (e.g. the Dunn & Bradstreet number) that will be in both systems, or we need to keep and maintain lists of all translations and that can be a hell of a job if you have millions of customers. The model also doesn’t tell us what a customer is. Is it a party who regularly orders goods from us, a party who once ordered something (some systems don’t record one-time customers), or a party with whom we have contact and may be able to sell to (e.g. a marketing database)? What are the underlying definitions for the entities and attributes in the canonical data model and how are they maintained? Achieving consensus about enterprise-wide data definitions is a major exercise and many organisations have struggled and failed with this problem. 

Question

I have a few ideas about how to address these issues and I’ll come back to that in a future blog, but first I’d like to know what other people think. Do all you architects recognise these problems or have you all solved them already?       

Footnote

 A break with the trend: a blog in English. Seems a shame to limit our audience when we’re on the World Wide Web!

« Older Entries