IT-eye

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

I am proud to announce that JaValid 1.2 release candidate 1 has been released today. Quite some changes have been put into this release of which the following are the most interesting:

* Introduction of a new type of validation annotations on class level, including several of these annotations (@NotNullAll, @NotNullOrNullAll etc)
* Added automatic resolving of messages (for user feedback) if needed
* Added new date validation annotations (e.g. @DateBefore, @DateAfter)
* Configuration minimized, annotations are registered by default now (for core and extensions)
* Added Spring AnnotationValidatorBeanPostProcessor (contributed by Scott Battaglia) which allows for validation of Spring Beans in an automated way.
* Advanced caching introduced (introspection is done only once when objects are encountered the first time), this improves speed.
* @JvGroup is not required anymore, only if you need more complex validation with multiple groups
* Core rewritten to allow more advanced validation features in the future

A lot more has changed than what is listed above, check the release notes for this.

You can download the new release from sourceforge. Also check out the documentation for all new features and on how to upgrade to the latest release.

For details please visit http://www.javalid.org