IT-eye

Probably, most people have by now at least heard of BPMN, the Business Process Modeling Notation standard from OMG that is supposed to be the process-modeling standard. I’ve been following news for the last 2 years or so but, admittedly, never really dug deep until I started using it at a client. Even then, it was mostly sales-pitch level and learning a bit of the notation from cheat sheets like the BPMN poster. The past few months, however, I have learned more about the standard – what its possibilities and semantics are and how it can be used. I’ve had training from both a more technical perspective (in an Oracle partner training) as well as from a purely modeling-oriented training (by one of the contributors to the BPMN 2.0 specification, Bruce Silver). And I must say, digging deeper has made me quite enthusiastic about the standard!

Read the rest of this entry »

My last blog about common information models (CIMs) gave a general idea about common information models. By now you might wonder what is purpose of using common information models is, so I will try to address this by explaining the strategic importance of standardization in digital information exchange, either business to business (B2B) or application to application (A2A). Read the rest of this entry »

Currently I’m working on my master of science thesis about designing an approach or recipe on how to use IEC CIM based messages in a top-down approach, starting with a business process chain and working my way down to information services and IT systems. As part of this thesis I recently visited the CIM User group Conference in Genval, Belgium, near Brussels. During this bi-anual conference, I learned a lot about how utility organizations in both Europe and North-America are performing digital information exchange using common information models. Read the rest of this entry »

As I stated earlier, I like to call myself an architect. Regardless of whether or not this is deserved, it means I myself am likely to be subject of at least one of these dogmas. While this makes it harder to discuss them without a bias or the tendency to defend my own position, it does offer the opportunity for a different type of discussion: one where, rather than pointing at a dogma and yelling out loud that everyone else is wrong, I can only do the pointing, then blush because I know I’m just as guilty. This is one of those moments (and probably not the only one ).

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!

A little break from the dogma’s of architecture here, as I’ve been thinking about something that I feel needs to be vented. I still have one or two more dogmas to post about, but they’ll come a bit later.

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!

One of the interesting things about architecture is how everyone is willing to say something about it yet so many of them limit themselves to their own area of expertise. So you get SOA architects, infrastructure architects, BI architects, process architects, business architects etc. While narrowing your scope to what you feel you can contribute to seems to make sense, such a narrow scope has a consequence: a company will have an “infrastructural architecture”, a “process architecture”, a “BI architecture”, etc. Essentially, we’re creating a sort of ’stovepipes’ of architectures, where the boundaries are determined not by the organization’s best interests, but by the limits within which its “architects” feel safe.

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!

The single most important part of an architecture is its principles. Principles, provided they’re well formulated, are the tools by which an architect determines what a colleague of mine likes to call the ‘degrees of freedom’ – the range of possible solutions that will not only work, but also help attain an organization’s goals. As such, it’s the principles that deserve the most attention, both in assuring their ‘correctness’ and in improving their formulation. I personally map them all out in a graph to visually display the causal relationships between various principles. And as quite often inconsistency in application of these principles is worse than picking a bad principle and sticking with it, us architects tend to take the hardline approach when it comes to implementing them. Our way, or the highway.

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.

Debating is a tough business. We rarely enjoy the feeling of ‘losing’ a debate – the fact that we call it ‘losing’ is significant in itself. So, we entrench ourselves in our positions. We won’t even consider counter-arguments to our own statements. We, thus, alleviate them to dogmas. In this post, I attempt to  drag another one out into the open: The Framework.

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.

Architecture is, quite simply, a bad term to use. Not only is it ‘loaned’ from a different subject area, which brings along a lot of (unwanted and confusing) connotations, it is also used for so many different activities within our own field that it is hard to tell what someone refers to when talking about ‘architecture’. By carrying many meanings, the term ends up carrying no meaning at all.

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

The Aquarium posted some lately stats about the usage of the Glassfish application server.
Nice to see it’s coming close at some points to the JBoss application server (i think the one which is his closest competitor).
At the 10th of february a nice heap when Sun announces his “Sun GlassFish Portfolio”.

If we take the stats of some other big competitors in the charts we’ll notice a few differences.
When we take oracle as and ibm websphere together with glassfish and jboss i guess the last 2 still got a long way to go, but they are growing!

comparing all 4
trend1
trend2
trend3

comparing glassfish and jboss
trend4
trend5
trend6

At this moment IBM and Oracle are still the big players on this market, let’s see what GlassFish will do in the near future since it’s getting more popularity lately.

Resources
my blog