Earlier this week I attended the Landelijk Architectuur  Congres in Nieuwegein. Besides the noteworthy percentage of attendees with mustaches, grey hair and ties, a pleasant and friendly event.

In the afternoon of the first day of the event I did a lively talk on shaping service oriented projects using smart use cases. During the talk I recevied some very peculiar feedback! Bare with me.

I addressed the possibilities smart use cases offer to model and implement new and existing business processes in smart use case diagrams. Using this approach front end, workflow and services become first-level citizens in the smart use case model, allowing not only to estimate and plan service oriented project more precise, but also to build up a solid repositry of services that are needed (and present) at a organizational (or domain) level – as proven in recent projects. Good stuff I would say. It adds to simplying such projects, instead of adding complexity

Colored smart use cases

For example, the diagram below resulted from a recent project. In this case, it combines both front end (orange use cases), workflow (purple use cases, realized in SAP XI) and services from different back end systems (green, yellow and blue use cases). 

Front end, workflow and services modeled in smart use cases

Defining unknown services?

Much to my surprise an architect in audience started shaking his head heavily during my presentation. Obviously, he didn’t agree. When I got curious and asked him about his misdemeanour he stated: “this approach doesn’t work because it only identifies services that are needed now.”

Althoough I think the technique allows for much more, I responded with a quick “So?”. “This is not service orientation,” the architect followed up. “This is only enterprise application integration.” It still didn’t worry me. After all, what’s in a name? But then it suddenly came out. “This approach does not allow you to defining services that you might need in the future, say in five years, but that you don’t know of right now.”

YAGNI

WTF! Was this guy serious? Guess he was. Unbelievable! This architect obviously has never of the YAGNI principle. Let me clearify what I mean by that in this particular case:

• Over-generic. Many software projects have gone under trying it make the software so generic that it will fit any future purpose. This makes writing software – service oriented or otherwise – hard to write and impossible to test.

  In reality, research has proven that of this generic software only 10% is actually used in future extensions of the code. That’s 90% wasted effort.

• The world changes. Moreover, trying to identify stuff that you will need in five years is a waste of time anyway. There’s no decent way to come up with requirements for software over that period. Simply because the world changes at high pace.

  Just imagine that you would have designed a piece software five years ago, and now need to build that. You would have missed the world wide financial crises, banks bankrupting, social media, Twitter, cloud computing, mobile possibilities, and likely even service orientation. Let alone changed legislation and government policies.

• Endless sessions. And it gets worse. Just think of the endless workshops and sessions organizations will start to organize to obtain these future requirements you don’t know of right now.

   
  Everything works on a PowerPoint slide

  I can see the PowerPoints coming out of those sessions, best printed at A0 format, full or requirements that will never be realised. But hey, everything works on a PowerPoint slide.

• YAGNI. Personally, I would prefer to design for business processes that organizations need now or in the near future, and that need to be automated now and not in five years. Thus, you focus on things that you can decide upon, and that can actually be designed. Think YAGNI.

Entering the twilight zone

So where does that leave us? To be honest, I kind of lost my cool during the presentation – although other people interpreted my response to the architect in the audience as pretty relaxed and quite polite.

But this head-shaking archtect perfectly stated what bugs me about (enterprise) architecture all together. Of course, I respect the idea that enterprise architecture focuses on the long term, and on strategy. But to actually think idea that you can endlessly embark on money-eating journey into the unknown future – easpecially given the current economy – is just not my cup of tea. It’s like entering the Twilight Zone. This is exactly why many large projects fail even before the first line of code is actually written.

 
Architecting feature unknown to mankind – yet

It’s about adding unknown complexity to projects that are hard enough to run even without us having to investigate possible use in five years. In contrary, we should strive to simplifying our projects. Exactly what I meant to do with modeling services in smart use cases.

I know I’m generalizing this a bit, but please, dear architects, let’s focus on reality and costs. Come down from your architectural cloud and be welcome to our twilight zone!