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). 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.” Although 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. 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.