Triangles Architecture

In The Future Enterprise (or today’s?) the revenue comes from splendid working (core) business functions delivered by services primarily or heavily supported by software. And to be at the top of the happy customers list enterprises need to change, to adapt to changing environments and to constantly improve and innovate their products. To do so is a tricky play where many things need to be in balance. This is what the Triangles Architecture is about.

There is a balance between three major themes which in itself are triangles of their own:

  • Triangle of Software Development Principles is a balance between Changeability, Testibility and Extendibility; out of balance this triangle will prevent evolution of your software
  • Triangle of Software Delivery Principles is a balance between Ownership, Decoupling and Automation; you need all of these and without it your delivery of changes will come to an end
  • Triangle of Process Principles is a balance between powers which influence the development and delivery of your product; out of balance you will have quick revenue without any future or you’re building the future without any income on short term

Logging Delegate

Logging is part of every application and we’re used to the lines of code which clutter our codebase with"something is happening here with {}" , var1); But is this great code? Or has this become the level of quality we’re familiar with? In the light of ”separation of concerns” (one and only one reason for change), ”same level of abstraction” (inspired by Clean Code of Uncle Bob) what would be the best practice to implement logging (without going to external solutions like AOP or alike)? Well, not really a question about the implementation of logging itself of course. SLF4J, LogBack, Log4j, Java Logging API and others are excellent implementations for logging info to a log file. The question here is about the best way to use a(ny) logger. Many developers will recognise the following lines (examples with org.slf4j.Logger):

private logger = LoggerFactory.getLogger(this.getClass());

or static final:

private static final logger = LoggerFactory.getLogger(MyClass.class);

and using the declared logger:

public String doSomething(final String input) {
  logger.debug("doSomething START met input [{}]", input);
  String result = businessService.executeLogic(input);"doSomething FINISH input [{}], result [{}]", input, result);
  return result;

The first issue with this code snippet is the difference in level of abstraction. Using the logger with the full info being logged isn’t the same level as the executeLogic method call of a businessService. The following snippet has more equal abstraction levels:

public String doSomething(final String input) {
  String result = businessService.executeLogic(input);
  logDoSomethingFinish(input, result);
  return result;
public void logDoSomethingStart(final String input) {
  logger.debug("doSomething START met input [{}]", input);
public void logDoSomethingFinish(final String input, final String result) {"doSomething FINISH input [{}], result [{}]", input, result);

Although it is getting better there’s still an issue about the separation of concerns. There is reason to change this class for the actual logic being executed, calling a businessService, but also for the logging info. To separate these concerns the logging methods could be extracted into a loggingDelegate as a second class beside the current class. Taking into account it is a best practice to program against interfaces this would double the amount of interfaces and concrete classes. Each BusinessService interface would have a BusinessServiceLoggingDelegate interface as would the implementations BusinessServiceImpl and BusinessServiceLoggingDelegateImpl. This is not really an improvement of the whole code base, is it?


Well, what about a separate class without having a separate .java file: an ”inner class”. The not often used inner class might provide a solution here. This will not totally separate the concern outside the .java file but separates it on class level. An instance of the logging delegate could be named logger for the feel of it. The LoggingDelegate class could extend a general abstract implementation with common features.

The result:

 * Example business service implementation only as example for application of the {@link LoggingDelegate} pattern.
public class BusinessServiceImpl {

    private LoggingDelegate logger;

    public BusinessServiceImpl() {
        logger = new LoggingDelegate();

    public String doSomething(final String input) {
        String result = otherBusinessService.executeLogic(input);
        logger.logDoSomethingFinish(input, result);
        return result;

    private static class LoggingDelegate extends Slf4jLoggingDelegate {

        public void logDoSomethingStart(final String input) {
            logger.debug("doSomething START with [{}]", input);

        public void logDoSomethingFinish(final String input, final String result) {
  "doSomething FINISH with [{}], result: [{}]", input, result);



On Github is the working code example of above extract:

A few final thoughts:

  • Applying this into a real world application my Sonar report does not improve with this pattern in place. On the contrary it decreases. So what is the problem?
  • One rule is not mentioned and forgotten: Is it testable? Maybe we should change the private accessor to default? And have some tests in the test companion object of the BusinessServiceImpl?


Triangle of Software Development Principles


When we develop our business functions we need to automate things. Automation means software. Software is cool. Software is called ‘soft’ because there’s no hardware, no hard things involved … BUT software is hard to develop. Here’s my Triangle of Software Development Principles.

Long time ago I learned the quote: There’s only one constant in software development: CHANGE. And it’s true. While we strive to build perfect software for perfect business functions with perfect teams … there’s always a reason for change. We gain new insight on our business function so we would like to have new features. So our business was not so perfect as we had in mind. Even before a new feature is released to our customers technology has evolved and our solution has ‘technical debt‘, a lag with the latest state of technology stack (which our competitor might use already). So our technology stack and software is not as perfect as we would like it to be. And even the team might strive for perfection we will always be learning and become more equipped than before to develop and optimise the way the team supports the business function.

So our software needs to be flexible, changeable, like clay. It should have a high level of Changeability.

On the other hand users might not be pleased with ever changing user interfaces. Other systems the business function needs to integrate with is not changing at the same pace and at the same time. There’s also some need of stability in our software. But in a way it does not frustrate the changeability. There’s a huge amount of books, blogs, website about good software design and principles and here are some examples:

  • Design patterns like
    • Open Closed Principle from Uncle Bob’s SOLID principles: Open for extension but closed for modification
    • Dependency Inversion Principle and the example of this in Inversion of Control / Dependency Inversion: Modules should depend on abstraction not on details (or ‘Programming to an interface’ in very short 😉
    • And DRY, Don’t Repeat Yourself, of course …
  • API First; thinking in APIs which are versioned and steady so decoupling is maximum and change is less likely to break things

All these principles are about how to design what should be changeable and what not. Therefore you need to think about the changeability of your software for things that need to change much. For the ‘harder’ parts you need to think about the Extendibility of your software. How to set it up that it can be stable but still open for extension and thereby still supporting change. This will generally be visible in abstraction, interfaces and such.

And while you have all this flexibility and stable parts going around and be changed the only way to prove the business function is still doing what it’s supposed to do is by testing. And the design should support the Testability. If it’s hard to test there’s a smell to it. You should rethink the design, the structure of the software and refactor it to improve. And support a higher level of changeability and extendibility which still supplies the business function in a stable way.

On the other hand tests will also make change harder. The way the tests are proving the business function are binding the changeability. So even the tests are eligible for these principles in itself.

So there’s a balance between the goal of changeablity against proving the product is still doing what it is supposed to do by the tests and to be able to still change easily we strive for extensibility which in turn downgrades the changeability. It’s a balance of a triangle, the Triangle of Software Development Principles.

Part of the Triangles Architecture

The Future Enterprise

Painful, monthly (or even worse quarterly) releases handed over by document based knowledge sharing to other people doing the actual deployment in production enabling the bureaucracy to the max … An era not long ago or even today’s reality. But … how can we change? How should my enterprise look like in the future? Close your eyes and envision: The Future Enterprise!

The Future Enterprise generating lots of revenue from happy customers using your core business functions supported by working software in all business functions accessible from everywhere, always available and all integrated. A culture of happy employees in an energetic, innovative environment who are committed to and contributing to the business goals. All aligned and supported by facilitating management focussing on building golden teams of excellent people with knowledge and capabilities to be creative, innovative and responsible.

Impossible you say? I don’t think so. Hard? Yes! Hard to get there … but growing there is fun already … most of the time 😉 There are a lot of ingredients involved in this roadmap. Even more if the company is still in the era of the painful, document based bureaucracy…

It all starts with admitting that the world has changed. Technology has become a disruptive part of our daily life. Personal life as well as our businesses. In every (core) business technology is emerging and becoming more and more important. IT (Information Technology) has become part of our core business!

The Future Enterprise is an organisation with well defined business functions (Enterprise Architecture) and teams organised likewise. And in every business function there’s an IT part. Not a separate part but an integral, essential part in the whole function. And so in the whole team. Automation is the way of supplying the business function to its customers. The team develops the business function with business functionality in mind and automation as the vehicle to deliver it.

A team in The Future Enterprise takes responsibility and are accountable for the business function they supply. The team exists of people who are capable, creative, innovative to develop, deliver and maintain a working service to their customers. Agile principles apply by focus on people and interactions, customer collaboration, working software and adoption for change. And working software means automation of everything from customer requests to infrastructure, deployment, recovery, testing and monitoring.

In The Future Enterprise the formal structure is about business functions and teams supported by facilitating management. Besides the formal structure the informal structure is supported by cross team communities. Communities support knowledge sharing, (cross team) relation building and interaction, fun events and innovation. It is in the cross-pollination of people and knowledge that new business functions will emerge of crazy ideas. And these new business functions need to be adopted to the organisation with a fresh new team. And now the future enterprise has grown in business functions and revenue.

In closing, again, this is hard to gain. But the journey starts today and is fun too! Maybe the future enterprise is about the journey and not about the future goal. It involves a different culture. Maybe it should start as a cultural change. Value people. Value great teams. Support teams to the max. Eliminate impediments of the teams (especially architectural and bureaucratic impediments) and trust the teams. Trust the people in the teams. The mapping of business functions on teams (or the other way around) will follow afterwards. Integration between business functions will follow afterwards. Set it as goals for the teams. And trust them to deliver it. Create new teams around business functions which were not supported (well enough). Focus on people and build great teams. The Future Enterprise will emerge at you faster than you can imagine. Happy journey!

See the Triangles Architecture for more details on how to realise the future enterprise 😉

De toekomst van een enterprise

[opiniestuk] De tijd van maandelijkse releases die mbv MS Word documenten door anderen in Acceptatie en Productie werden geīnstalleerd herinner ik mij nog goed. Pijn. Moeite. Frustratie. Bij mij. Bij hen. En procedures. Heel veel procedures. Voor een Enterprise, een (groot) bedrijf is dit niet lang geleden of zelfs nog actueel. Maar in een tijd dat de technologie zo aanwezig is in ons dagelijks leven, waar we met onze smartphone opstaan en naar bed gaan, waar we televisie kijken niet meer televisie kijken kunnen noemen, want wie kijkt er nog op dezelfde tijden naar dezelfde programma’s? Hoe gaat een Enterprise hier mee om? Hoe pas ik mij aan? Moet ik mij aanpassen?

Het antwoord is natuurlijk: JA! Aanpassen moet. Waarom? Om te overleven. Om te blijven bestaan. Om te kunnen groeien. En … omdat het leuk is! De nieuwe wereld is FUN! De nieuwe wereld helpt. De nieuwe wereld is beter 🙂  Hier volgt mijn persoonlijke view op de toekomst van een Enterprise.

In een Enterprise, een groot bedrijf, is er behoefte aan verschillende functies. Elk bedrijf wil inkomsten genereren met hun ‘core business’. Deze core business bevat veel IT en automatisering. En dit moet ‘top of the bill’ zijn, want hoe beter en mooier, des te meer inkomsten er gegenereerd worden. En elk bedrijf heeft vervolgens de noodzaak om die pegels dan ook binnen te halen. Met andere woorden: factureren, klantbeheer, support, etc. En elk bedrijf heeft medewerkers en (dus) een HRM systeem, hardware (laptops, telefoons, etc) en andere infrastructuur om te kunnen inloggen en ‘je ding te kunnen doen’. Elke functie wordt apart geleverd in de Enterprise en alle functies integreren met elkaar.

Elke functie bevat een groot deel IT en automatisering en elke functie wordt geleverd door de best passende oplossing. Voor de standaard functies zijn dat vooral kant en klare services afgenomen bij een leverancier. Functies die niet goed geleverd kunnen worden door leveranciers of beter geleverd kunnen worden door zelf te ontwikkelen, worden zelf ontwikkeld. In alle gevallen heeft elke functie een eigenaar en een team van mensen die zorg dragen dat de functie goed wordt uitgevoerd en verder wordt ontwikkeld. Nieuwe functionaliteit, ondersteuning en garantie van de beschikbaarheid. Van elke functie is bekend wat de toegevoegde waarde is (in geld) en wat de kosten zijn. En in een gezonde Enterprise levert elke functie meer waarde dan dat de kosten zijn 🙂

Om de integratie gemakkelijk te maken met allerlei leveranciers van functies is elke functie direct toegankelijk via het internet. Klanten hebben alleen een browser nodig, tenzij specifieke software nodig is natuurlijk (bijvoorbeeld GIS pakketten oid). Medewerkers hebben (ook) alleen een browser nodig. De functies die zij gebruiken, zijn onafhankelijk van de hardware waar zij mee werken. Is dat een laptop van enig soort of een tablet of een (lightweight) desktop? Geen verschil en geen onderscheid in gebruik. Nogmaals: dit betekent dat alle functies via internet toegankelijk moeten zijn en allemaal met elkaar moeten integreren.

Er zijn verschillende functies. De belangrijkste functies zijn natuurlijk de core business. En er zijn primaire functies die de core business ondersteunen. Er zijn ook (veel) ondersteunende of secundaire functies nodig om alle primaire functies te ondersteunen. Medewerkers moeten kunnen inloggen en met hun account (één en niet één per functie) geautoriseerd gebruik kunnen maken van alle functies. Inloggen en het beheer van hun identiteit is een ondersteunende functie (tenzij dat de core business is natuurlijk 😯 ). En ook ondersteunende functies moeten toegankelijk zijn via het internet. Bijvoorbeeld voor authenticatie betekent dit dat medewerkers een publieke identiteit moeten hebben. En dat elke functie (waar autorisatie van toepassing is … en welke is dat niet?) ondersteuning voor deze identiteit moet hebben.

Naast toegankelijkheid via internet is elke functie altijd beschikbaar. Altijd als in 24/7 met alleen onbeschikbaarheid bij calamiteiten. En deze zijn er weinig tot niet (toch? 😉 ) Dat houdt in dat functies met nieuwe functionaliteit worden uitgerold zonder onbeschikbaarheid. Misschien incidenteel nog korte en geplande ‘in service’ onbeschikbaarheid? Maar meer zeker niet! Ook niet als de functie veel meer gebruikt wordt dan oorspronkelijk verwacht en ontworpen … Niet ten ondergaan aan eigen succes. Nee, elke functie kan eenvoudig (en automatisch?) opschalen om hoger gebruik te ondersteunen. En nieuwe functionaliteit wordt uitgerold terwijl gebruikers er mee werken.

Maar …

Maar hoe? Hoe doe ik dit? Hoe doe ik dit als een bestaande Enterprise … met pijnlijke maandelijkse releases?

Tja, als bedrijf met pijnlijke maandelijkse releases is de verandering wel heel groot. Bovendien ontwikkelen functies zich zo snel dat een langzame verandering te kostbaar is en/of wellicht niet haalbaar. Ik vraag me af: Is het mogelijk om nieuwe (versies van) functies zoveel mogelijk naast de bestaande functies op te bouwen en te integreren? Als een aantal functies echt top werken en alleen de integratie is nog wat moeizaam, moeten de kosten dan niet in de integratie gaan zitten ipv in matige functies leveren? Anyways, eerst maar eens de ingrediënten benoemen die voorwaardelijk zijn om de Enterprise van de toekomst te bouwen.

In het kort: Agile. Maar wacht! Niet Scrum. Niet ‘wij zijn een Agile bedrijf en we werken zo’. Nee, míjn Agile. Agile zoals in het manifesto beschreven. Het gaat om mensen. Het gaat om werkende software. Het om samenwerking. Het gaat om je aanpassen aan veranderingen. Agile zoals ik dat zie …

Agile (voor mij) gaat om mensen. Mensen doen het. Mensen maken het. Mensen zijn het. Elke functie wordt vertegenwoordigd door mensen. En alleen zij kunnen de functie een top functie maken. Wie zijn de mensen die het beste een functie kunnen leveren? Wie zijn het gouden team? Dát zijn de mensen die die functie leveren. Dáár draait het om.

Agile (voor mij) gaat om werkende software. Altijd werkende software. Goed werkende software. En het team dat de software / functie levert, staat daar ook voor. Hoe? Het team garandeert dat de software werkt. Het team garandeert dat de software draait / beschikbaar is. Hoe? Door dat te doen om die verantwoordelijkheid te kunnen dragen. Hoe? Continuous Delivery (met oa Automated Testing, Automated Deployment). Monitoring. Scaling en Automated infrastructuur, lees: Cloud. Cloud is het automatiseren van infrastructuur … en alles wat daar boven op terecht komt. Werkende software is een service die geleverd wordt en afnemers van die service maken er gebruik van zonder zorgen over beschikbaarheid en werking. Het werkt gewoon.

Agile (voor mij) gaat om samenwerking. Mensen werken samen. Gebruikers, medewerkers, teams, teams van teams. In welke vorm wordt de beste samenwerking bevorderd? Hoe kunnen we goodwill, vertrouwen, transparantie, eerlijkheid, creativiteit, innovatie, plezier verhogen? Dan pas draait het om mensen. Dan pas werken we samen.

Agile (voor mij) gaat om aanpassen aan veranderingen. De wereld waarin we leven. De wereld van een Enterprise. De toepassing van een functie. Het verandert. Het is niet de vraag ‘of’ maar ‘wanneer’. En daar kunnen we beter maar op voorbereid zijn. Verwacht verandering en pas je aan. Als mens. Als team. Als functie. Als bedrijf. Als Enterprise.

Gemakkelijk? Nee. Mooi? Ja! Wat is het leuk om de saaie taken te automatiseren! Wat is het leuk om verantwoordelijkheid te dragen en te kúnnen dragen! Wat is het fijn om nuttig te zijn! Wat is het cool om top functies te leveren aan blije gebruikers! Wat is het cool om met andere leuke mensen te werken! Wat is het leuk om in een inspirerende Enterprise te werken!! Dát is de Enterprise van de toekomst!

To WordPress or not to WordPress

Right … Here’s my new site. Well, a brand new domain name and fresh new content! And really with WordPress this is just peanuts!! Quite awesome I would say… But is it really that cool?

Martin Fowler started a ‘bliki‘, combination of blog and wiki, to post his thoughts, work on them and develop them as life goes on. Is WordPress something like that? Or at least applicable for that? Or is it more of a ‘blogger host’? So no really wiki like pages? Or … well, I don’t know (yet).

For now, I’ll just stick to WordPress. It seems to be really easy to use, to configure and to maintain. As a pro automator (= developer) I’m as lazy as … well, let’s say lazy, so I do like easy 😉

© 2017 Marc van (powered by WordPress)