Probably it did, actually. While IT and Business architecture isn’t really the same, the original field of architecture works well as a metaphor. It’s such a natural comparison that it doesn’t feel as a metaphor. Plus, it fits kinda neatly – as long as you don’t look too close. And that’s exactly where the metaphor loses its value, both because the layman’s knowledge of brick-and-mortar architecture proves inadequate and because, in the end, the fields are just not the same.

Still, metaphors have value in communicating different aspects of architecture. So I’d like to explore different perspectives on architecture using different metaphors, starting with: navigation!

‘Turn left after the next project, onto new middleware street’

Most of us know what a navigation system is, right? Disregarding the humorous mistakes these things can sometimes cause, they can make our lives a lot easier. Just type in your destination, your preferred type of route, and it will calculate a route for you. Easy as pie, isn’t it?

Well, no not really. There’s a lot going on below the surface which needs to be arranged for a navigation system to function properly. Think about it:

1)      How would you like to travel? Shortest distance? Fastest route? Avoiding highways? By pre-set waypoints? Only traveling outside rush hours? There are so many options, all of which affect how ‘good’ a certain route is.

2)      The environment isn’t static, but dynamic. Traffic jams grow or dissolve, road work temporarily closes down stretches of road, or 50.000 football fans celebrating their team’s first championship ever bring your progress to a standstill. So, you need to be in touch with the world – to be connected – and to constantly recalculate your route.

3)      How do you know you’ve arrived at your destionation? The system will need both a ‘test’ – co-ordinates – and a ‘method’  - GPS – to determine whether or not you’ve reached your destionation.

4)      Last but not least, there’s you! Because even if the system gives you a perfect route, with perfect driving instructions, it does not drive the car. That´s what you are for – the driver. And you can choose to do whatever you want, including completely ignoring the instructions and taking a different route.

Comparison to architecture

So, what does this comparison show us about architecture and the process by which it is implemented? Your destination is your business strategy – it’s where your company wants to be. The actual architecture are the co-ordinates, or the manner in which you can test if you have arrived at the destination. The route are the changes you make to your company. It could be implementing new middleware, changing process owners and service-enabling existing applications. I’ll leave the interesting question of who the driver is in this metaphor for later. Let’s first look at those 4 aspects:

1)      The preferred route. The same thing exists in IT architecture. Do you want to use current personnel and expertise? Would you prefer to sit out your system lifecycles before updating them? Do culture changes preceed or follow technology changes? Questions that impact not only the timing, but also the architecture itself!

2)      The connection. This is so very crucial! An architecture team needs to know what’s going on. Where do projects stall (traffic jams), what projects are going on that should work under architecture (road work), what stakeholders are likely to resist the architecture (the fans blocking the highway), all of that influences the route while driving it.

3)      The destination. As said, the business strategy is your destination. The architecture itself, with all of its principles, guidelines and models, is how you test whether or not the company – or rather, its operations – is ‘there’. Far more complicated than in navigation, indeed.

4)      The driver. Someone drives the car. That someone can’t be the architect – he’s the algorithm, the heart of the navigation system. So who is? Well, looking at the metaphor, shouldn’t the driver be the one who actually wants to be at the new destination? And, thus, a representative of the organization, such as a board of directors or a ‘business board’ or something?
But most importantly: the car isn’t being controlled by the navigation system, but by the driver. This holds true for architecture as well: the architect isn’t driving the organization, but the business representative is. They have to choose, they are in control of the route.

Lessons learned

So, what can we learn from this metaphor? A quick summary…

• An organization will have to do the driving themselves. For which they should be happy.
• You can deviate from a route. A good architect will lead you from your new position to your destionation. Just give him/her time.
• Of course, if they want to do that, architects have to know what’s going on, or they can’t adjust the route to the current conditions. So keep them in the loop.

Any more lessons (or metaphors) that are worthwhile? Please comment!

Permalink | No comments | del.icio.us | Technorati | digg | dzone | StumbleUpon | Architecture

Even now, in BPMN 1.1, the clarity of modeling in BPMN as compared to the clarity of, for example, activity diagrams is stunning. Especially the addition of several types of events, both throwing and catching, and the definition of gateways and other methods to handle these events allows an extremely precise process model. Just as a quick – and very simple – example, consider the process of handling a customer’s RFP. After receiving the RFP, you send a proposal, then wait 5 days for a reply before cancelling or closing the deal. Ignore the fact that this is bad salesmanship, please, that’s not what I’m being paid for

In a basic UML-activity diagram you would model this as follows:

Seems clear enough to you? Perhaps. Now consider the BPMN diagram of this exact same scenario:

The gateway being used here is the ‘Exclusive Event gateway’ which should basically be read as ‘whichever of the following events occurs first, follow that path and ignore all others’. Notice that not only does the gateway give more detail in (structured and validatable) symbols instead of (unstructured and unvalidatable) text, the diagram also presents more information that could not be given in the other diagram, such as the message flow and the start and end points. At least, not without adding undefined, unstandardized notation. Everything used in the BPMN diagram above, up to the type of arrows and whether or not an event symbol is solid (‘filled’) or blank (‘empty’) is defined in the notation. No more ambiguity!

The drawback here is that, for this to work, you have to have at least a basic knowledge of BPMN – such as what an event gateway is. Still, if you’re looking to standardize process modeling, look into it. It’s worth the time and effort, especially once you learn some basic ‘patterns’ that are common in process models, such as error handling, error throwing & catching and the pattern used in the above diagram, the time-out event. It certainly got me enthusiastic!

Permalink | One comment | del.icio.us | Technorati | digg | dzone | StumbleUpon | Architecture

In the digital age, this flow of materials is heavily supported by a flow of digital information between the information systems from all organizations in the value chain. Now, this information flow can designed and developed into software components in ad hoc solutions and point-to-point integration, but this will ultimately lead to a relative high cost of ownership for the life-time of these software components. Also, the ability of these software components to interact with other systems (aka interoperability) over the entire life-time will be moderate because of the lack of standards within one organization and between the connected organizations.

To get round these problems and enable global open markets in which all organizations speak the same language and use the same semantics while exchanging digital information, several communities and associations like IEC, ISA, OPC,  ebXML, OAGi, and more are creating (cross-) industry standards for exchanging information between organizations (B2B) and applications (A2A) using so called common information models (CIM). Some of these communities offer open standard models that can be used free of charge for developers of software systems and others are only accessible for paying members.

The difficulty is to find a suitable CIM standard and find consensus about this standard model with our business partners. Knowledge of the available CIM standards provided by the different communities is required to make this choice.

When a standard is chosen, the next challenge is how to merge this standard in your IT-landscape. When you already have a corporate data model or a canonical data model (CDM) in place, this challenge is a minor one. However, if no CDM exists, the CIM standard can help in defining a CDM. Two flies in one stroke! This is a major challenge, however because creating a CDM typically takes time. Creating a CDM is typically something that is part of the enterprise architecture and has (should have) strategic value.

Finally, when the CIM is merged with your CDM, software components which exchange messages based on the CIM standard can be developed or bought. This is the easiest part of the whole exercise because all message definitions and flow are already defined by the CIM standard and developers don’t have to worry about this. Software vendors like Oracle and SAP offer these software components. For example, Oracle’s AIA offering uses the OAGi standard (among others)  in their solution.

Additional side effect of using a industry wide standard is that you can use it as a selection criteria for commercial of the shelf (COTS) software. This will likely reduce the implementation cost of integrating these software into the organization.

Government: although the example used above is about manufacturing and retail, it also applies to governments as well. The products in the value chain are translated to licences and official documents and etcetera. A typical government also has business partners. In the Netherlands these are typically the providers of the GBA, BAG and other (local) governments etcetera. Take for example the process of a person that moves from from city A to city B. These information (GBA) is exchanged via the so called Overheids Service Bus. The common information model used here is the Referentiemodel Stelsel van Gemeentelijke Basisgegevens (RSGB), using Standard Uitwisselings Formaat (StUF) as the universal standard exchange format, the national standard for the government sector.

Permalink | 2 comments | del.icio.us | Technorati | digg | dzone | StumbleUpon | Architecture

Possible drawback of using CIM standards in general, in my opinion, is that it requires additional startup costs to learn and use the standards in respect to “just” do it quick, and with the posibility of doing it dirty also. So, the costs of adopting this standard approach in your information services will payback after a number of integration projects have completed. Also, I noticed that some TSOs are trying to use EIC CIM as their corporate data model, which I think is wrong. IEC CIM is designed for information exchange, so it should only be used primarily for information exchange areas which typically should be a subset of the total corporate data model. Finally, using IEC CIM as corporate data model is equivalent to trying to model the (your) world in one big model, which inevitably will lead to sematics issues. As en example take the entity Account. This entity has a different meaning and hence different attributes for a sales person than for a financial controller in the same organization.

On the other hand, the nice thing of communicating via an industry-wide common information model is that it likely might save work during information exchange and transforming messages from chain partners and interfacing with COTS-systems because the message definitions and semantics are standardized. Adhering to industry standards often lower the life-cycle cost (or in other words TCO) of B2B interfaces and increase the interoperability of IT systems using the B2B interface.

Permalink | One comment | del.icio.us | Technorati | digg | dzone | StumbleUpon | Architecture

Everytime I write an architecture, I strive to make it ‘understandable’ for people without a background in either architecture or IT. On some level, it makes sense: what I’m trying to do is hand over guidelines to people without such background, which would be hard if they couldn’t understand a thing I’m saying. So, I describe the architecture in natural and understandable language – not stupidly simple, but without jargon and without overdone verbosity, outlining both the statements I make and the reasoning behind them. The end result is a clear document, that doesn’t devolve into expositions in jargon about the formulation of a principle, isn’t 500 pages long and is generally quite readable.

Then that exact document is only read by people with exactly the background I wasn’t targeting – software engineers, the various types of architects and, if you’re lucky, a few managers close to IT (and all of them complain that it doesn’t give enough detail; but that’s a different subject…). But it’s not read by the audience I targeted. Yet, next time I describe an architecture, I’ll do the same thing.

Of course, I might be alone in this. Others might opt to forgo the ‘readable’ criterion (or at least adapt it for a different audience). Yet others might actually get it to land in my target audience. I’m a bit at a loss what, and if, I should do to ’solve’ this dogma. To me, a dogma it is and, considering what I still use as my definition of architecture, a dogma it will stay.

On another note, for now, I’m out of material for this series. Feel free to suggest some other dogmas in the comments!

Permalink | One comment | del.icio.us | Technorati | digg | dzone | StumbleUpon | Architecture

As everyone must have noticed, the world as a whole is struggling with two prominent themes at the moment:

In one corner, weighing in at billions in damages from lost income, unemployed workers (and their families) and bankrupt companies, is the global economic downturn. It is the grand cause of most companies focusing on cost savings nowadays, and has also caused us here at IT-eye to put extra focus on the cost-saving capabilities that IT can deliver.

In the other corner, weighing in at a global destruction of ecosystems, melting icecaps and the possibly permanent change of climates in every part of the world, is the issue of climate change. Climate change, like the economic crisis, has caused a massive shift in how companies approach their own business system, but mostly, how they approach their market. ‘Going Green’ is hot and, even despite the economic downturn, willingness to contribute or, at least, to appear to contribute seems higher than ever. Just search for ‘Going Green’, and you’ll get millions of results – often combining Green and cost-saving.

What do these have to do with each other? Well, the combined effect of these issues seems to be an increased interest of customers not only in what they’re getting, but also in how a company delivers. To me, it feels like banks can reap massive benefits from an image of decency and sensibility now, as opposed to those currently ‘falling down’ from what is perceived (rightfully so, in my humble opinion) as ‘greediness’. In other sectors, look at Google and its ‘Don’t be evil’ adage, and its continued focus on stimulating research on renewable energy.

What this seems to indicate is that there is a competitive advantage to be gained from image. This, of course, is not new – brands and their delivery are key aspects of managing a succesful company. But I’m wondering if the current global situation is causing enough shifts in this to make the question of how a company delivers important enough to base a strategy on it. In essence, what I’m saying is that Treacy & Wiersema’s 3 value disciplines, or Porter’s Generic Strategies, might need revising. Remember those? Treacy & Wiersema proposed three distinct ways in which companies could deliver unique value to customers:

1. Operational Excellence, or focusing on price & ease of purchase & use
2. Product Leadership, or focusing on innovation & features of your product
3. Customer Intimacy, or focusing on customers & delivering tailored solutions

I propose to add a fourth to this:

1. Consumer Trust, or focusing on building an image of being responsible & considerate of the impact of the company’s actions on environment and society

This requires thought on its consequences and how it differs from the other three value disciplines. Will it be a sustainable source of competitive advantage, or will it die out as soon as the economic crisis (or the climate change crisis) has blown over? Worth a thought!

Permalink | One comment | del.icio.us | Technorati | digg | dzone | StumbleUpon | Architecture

To me, the most flagrant example of this are the disparate architectures for a BI solution and for process support. BI and process automation are two fields where my employer excels in. They’re also very closely linked. To me, it makes no sense at all to consider an architecture for one without at least knowing the key points of the other’s architecture. Consider, for example, the following points:

-           Intelligence systems are mostly fed with data derived from a company’s operational and supporting processes.

-           Intelligence systems are used directly in the execution of some processes. Think, for example, about the possibilities of feeding a knowledge worker with information about the consequences of previous decisions he made. Or the possibilities of complex event processing, which requires the capability to identify and recognize patterns as they occur.

-           Processes can be improved in BPM or BPR projects based on information from intelligence systems. Round-trip engineering and simulation are two, very, hot topics covering this at the moment.

-           Operational processes can give a context within which to judge information derived from an intelligence system.

And I’m sure that’s not all of it. Simply said, one cannot be regarded without knowledge of the other.

That’s not to say that there are no parts of an architecture that are specific to one subject area. The specifics of how to design a data warehouse is of no interest when designing a process application. However, the architectures influence each other, and choices made in one will influence the degrees of freedom that can be offered in the other. This is why they are not separate but linked.

Let’s look at an example.  Say that I design a “BI architecture” – an architecture that deals with the way information is spread and used in the organization. Part of my BI architecture concerns the way data moves from operational systems to intelligence systems – the ETL process. As my organization is light on knowledge workers, we envision a mostly management-centred intelligence systems that aims at monthly reports. For efficiency reasons, the choice is made to only move through the ETL process once a month as well.

At the same time, a process architecture is set up separately. At the foundation of this architecture is a process redesign effort in which more responsibilities are given to the workers executing the process. In essence, the process architecture envisions a shift to knowledge workers. Of course, these knowledge workers will need more and more recent information; preferably real-time. Unfortunately, our new BI architecture will not be able to supply this.

While this might be a fairly simple and straightforward example, reality offers far more complex situations, with many more aspects, consequences and subject areas that will have an influence on each other. It is, of course, undesirable (and impossible) to consider the entire organization every time you wish to make a slight change in one aspect. Preferably, that’s the role of enterprise architecture: to lay down the degrees of freedom for the more concrete architectures to operate in. But if those boundaries are not set, at the very least an architect can consider how their own choices influence the options left in other architectures to achieve the goals and implement the strategy of the organization as a whole.

I guess it all comes down to the same basic thing again, doesn’t it? Communicate, share & cooperate!

Permalink | 2 comments | del.icio.us | Technorati | digg | dzone | StumbleUpon | Architecture

The following, then, will be the consequence of this hardline:

“Architecture and architects are annoying. They’re constantly trying to limit the options you have for solving <insert incredibly hard and important problem>. All they’re doing is spending time producing a lot of hot air and meaningless words. Then, when they’re done producing unintelligible, far from concrete garbage, they expect us to adhere to it – always and without exception. They’re being way too principled!”

While I presented this remark with a decent amount of artistic license, I’ve heard it myself often enough (jokefully, I hope). It’s not a fun accusation to get thrown at you. Essentially, what they’re saying is they want more freedom to deviate from your principles.

What? How dare they! I put in a lot of work to formulate those! I checked relationships, consistency, choice of words and consequences. I tested them with key stakeholders. How dare… wait, why do they actually want to do something else?

While principles are formulated in such a way to be timeless and generally applicable, they really are just that: generally applicable. All this means is that in most situations, the principle is ‘correct’. There will always be situations, however, where someone can put forth a good case to do it differently. In addition, sometimes my principle might actually be wrong – it could be that the situation has changed or just that I misjudged it. Rather than suppressing every initiative to change a principle, hear them out – it might benefit your architecture.

Permalink | No comments | del.icio.us | Technorati | digg | dzone | StumbleUpon | Architecture

The framework proposed in the NORA (Dutch Governmental Reference Architecture)

One part of every architecture I have seen is the framework. Every architect knows at least one of them. It all started with Zachman and TOGAF, but nowadays there are dozens of (often only slightly different) frameworks. Every author naturally defends their own framework, but many architects also have their own ‘favorite’. And we swear by it. Using ‘my’ framework has, in short, become a dogma.

Lets look at what a framework is. Most frameworks offer – with different emphases and in different amounts – a combination of:

1. A grouping in which you can fit the architecture (such as the above image)
2. A process by which you can arrive at the architecture and/or keep it up to date

Both of these aspects are used to guide the architect in delivering the architecture and by that – hopefully – increase its quality as well. It is, as such, aimed primarily at the architect. Looking back at the goal I gave for architecture in my definition, architecture is aimed at decision makers – process owners, application designers, etc. Rare is the decision maker that has a knowledge of architecture and the specifics of frameworks. I think it’s safe to say, then, that the framework isn’t aimed at them!

So if, then, the framework is just a tool in the architect’s toolbox, diverting focus from an architecture’s content onto the tools by which it is created seems, to me, to be counterproductive. Let it be an internal discussion at best and don’t burden the client organization and the architecture effort by dragged-out discussions or terse efforst to ‘convert’ from one framework to another. So, rather than being dogmatic about what framework to use, just pick one and go with it.

Permalink | One comment | del.icio.us | Technorati | digg | dzone | StumbleUpon | Architecture

As I call myself an architect, this hinders me in my work. People I talk to expect things or have preconceived ideas that make a conversation about architecture hard, as we constantly have to clear up the miscommunications. My preference is thus to just avoid the word altogether. At least that gets rid of the preconceived ideas.

So, when I want to do any blogging on architecture and, such as now, talk about its dogmas, it couldn’t hurt to give my definition first

To me, the goal of an architecture is to support people making decisions on how to design their operations. That’s still vague, so let me make it a bit more concrete. An architecture makes statements about the direction in which the decision maker should look for a decision (or solution). The subject matter is of no consequence; as long as it’s a part of an organization’s operations, it can be part of an architecture. So an architecture could cover:

• Processes (both business and IT and both primary and secondary)
• Applications
• Employees
• Organizational structure
• (Technological) Infrastructure
• Facilities (Yes, I’m talking about furniture and lighting here)
• Marketing
• Etc.

Why such a diversified set? Simple. All of them impact the success with which an organization can reach its (strategic) goals. In fact, without covering all those subjects, how can a company really use architecture to improve the success of its operations? While it would still have value for the subjects it did cover, it wouldn’t be complete and thus miss a lot of potential and synergy.

Not that I’m suggesting that you need a grand, 50-page document for every subject you cover. Nor do I suggest that this grand vision of architecture should be used by everyone. However, it gives you a bit of context within which I will be discussing architecture’s dogmas during the coming weeks. At least that way, I can use the word itself

Permalink | 2 comments | del.icio.us | Technorati | digg | dzone | StumbleUpon | Architecture