Translate

March 25, 2017

This is the canvas your office walls are missing...

... just in case you read my previous post on the Dutch excellence in IT Architecture; No this is not a post about Rembrandt or Van Gogh. If anything, it's close to Mondriaan. The canvas I'm talking about is the Business Model Canvas, a Swiss invention in case you were wondering, made by Alexander Osterwalder. Both the Business Model Canvas and Alexander Osterwalder are featured on Wikipedia. Okay, here's a little trivia. Alexander Osterwalder was born in 1974 in the Swiss city Sankt Gallen. Fact is that I lived in St. Gallen 20 years later, when I did my internship at a Swiss company while studying Computer Science at a Dutch polytechnic. Coincidence? Maybe, but maybe it was ... well don't let me get there.

The importance of the BMC is that it allows people to make the right decision when they need to prioritise their pending activities. This is why you need to print it out poster-size and make sure that everybody in the organisation can at all times take a look at it from their desk. The BMC should be ingrained into your organisation!


So, the BMC. I think it's probably the most important model you as an architect can work on with your team and than print it out and give it a triple A location on a wall in your office. Printed such that everybody can see what's on it from any angle. And just in case your office has more than one room, make sure you print one for every room.
Just so your organisation's mission doesn't get lost, print it on the same poster above the BMC. Oh, by the way, you can also ask your management, your CEO, your board of directors, to give you the canvas so you don't have to create it yourself.

The reason for the importance of the BMC is that it very clearly documents why you're doing all that you're doing. And if you can't explain why you're doing what you're doing by means of the BMC, stop doing it.
The magic of the Business Model Canvas is that it helps you, initially, to write down what you think your business is. Business here is meant in the broadest sense of the word, so even when you're in an NGO, a not-for-profit, some form of governmental organisation or a commercial business, the BMC is crucial, especially the activity of filling the BMC. It should be your primary source of focus.
What is the BMC? Without trying to go too deep into the topic, here's a little extremely short primer. Do a quick Google or Bing search to find out more about the BMC.

The BMC has 9 fields that are desperate to be filled with your input. They're divided horizontally as well as vertically. Horizontally you see on the bottom the money flows, what's coming in, Revenue Streams, and what's going out, Costs. On the top you'll find 7 fields that correspond to your organisation, they explain all about the 'why' of the money flows. Who's your customer, who are your partners, what's your product, etc.
The vertically there's a split right in the middle. In the middle you find your product, what ever that may be, it even may be a service. On the left you find everything need to create that product or to deliver that service. Notice that this is on top of your costs, since input for product creation or service delivery requires payments, i.e. costs.
On the right you find everything that is needed to create a revenue stream through your product or service. Customers, channels through which to sell and of course customer relations to keep customers happy and invite them to purchase more.

As you can now see, every aspect of your organisation and it's (business) value is captured in one model. You should read about my view on models, which you can find here. The reason to read my view, is to understand why I'm a bit hesitant when talking about models. But also to understand that the BMC, which is a visualisation of your business model, is one of the best models out there because it so clearly defines what single aspect of a business or organisation it visualises.
Anyway, having a BMC allows you to ensure that your activities are related to what your organisation attempts to achieve, being creating value that is sustainable and in line with your organisation's mission and vision and is according to it's strategy to realise this vision. Say what? I need to formulate a mission and a vision as well and come up with a strategy? Well, uhm, uh, duh! I would be worried if you hadn't done so already. So I'm assuming that you have, giving you the benefit of the doubt.

One very practical way of filling in the BMC is to gather everybody from the management team in a single room and do a 3rd third workshop.
The complete management team should be in the workshop because they need to not only understand what the business model is, but also why it is the way it is. And understand everybody's input. Furthermore, all areas are related to each other.
When you're in a startup, this workshop can be with just the founders, or maybe when you're really at the early stages, it's just you. In a larger or more established organisation or if you're catching up with the BMC, you should involve all of the MT team, or maybe the members of the board. Just get all the executives in the room to do the workshop.
With respect to the BMC, limit yourself to the upper 5 fields and address them one by one. Take a full day, limit the total time for each field to 60 minutes. And make sure that you have a healthy refreshing lunch and a nice diner afterwards.

That's the recipe for a BMC, but what of it? What you'll notice is that when you work on the BMC, even without the 3rd third approach, some of the fields are easy to give some content, and some seem almost impossible. Now forget about the first category. I'm sure you'll manage. Heck, you'll be probably in need of restraints to keep you from talking about it. Focus on the hard ones, that's where you'll be able to gain the most from the BMC.
Typically the easiest is the Value Proposition, especially when you're a startup. When you're an established organisation you might find that one harder to do because you've diversified your business, and possibly too much.
I would say that you need to focus on your customers first. And make sure you've got some names of people you can contact. A good way to address this is to come up with a sample group of 5% - 10% of your customer segment that you can contact directly. When your market is smaller than 500 customers, consider the lower end of the 5-10%, when your market is larger... you get the drift.
These are the customers that you'll use to validate the rest of your BMC.
Now first validate your value proposition with your customers, use your sample to do so. Chances are your customers don't think your product or service will help them (optimally) or are not willing to pay for it or something else. There's a ton of ways to do this. Interview them, have them sign-up for a pre-order, start a Kickstarter campaign, etc. The point is that you need to make sure that your value proposition is feasible to pursue. And now keep on listening to your customers and keep them informed. And after reading this, you also know without me telling, that you need to make sure that your contacts will provide reliable feedback. You're building your BMC and therefore your business on their feedback. And before I forget, make sure that your vision and strategy are also taking this feedback into account.
Once you've got your customers and your value proposition filled, it's time to do that workshop and fill in the other fields. Make sure that they're in line with your customers and your product. But also make sure that they're in line with your mission and your vision. And strategy of course.

Which takes me to the lower half of the BMC, the money flows and how to address them. You'll need to make sure that you know how to make money from your product, or rather what determines your income. And you need to know where your costs are coming from as well.

The importance of the BMC is that it allows people to make the right decision when they need to prioritise their pending activities. This is why you need to print it out poster-size and make sure that everybody in the organisation can at all times take a look at it from their desk. The BMC should be ingrained into your organisation! It also means that the BMC has to be communicated to everybody. There shouldn't be anything secret about the BMC. When it is, you're screwed because you need to take a very dictatorial management approach with micro management. And if you take that approach you won't have time to generate your revenue streams to cover your costs. Think about it, it's one sheet of paper, what secrets can you fit on one sheet of paper anyway?
So you want everybody in your company to know what your business is, and how you think it can be sustainable. It will allow everybody to evaluate whether their actions are helping the business, create business value, or not.
And it goes beyond this, think about new product development or new features to existing products? Just one look and discussions about wether or not to do it can be rendered irrelevant. Marketing campaigns? Whether or not to do them is written on the BMC. Deciding about whether or not to partner with somebody? It's in the BMC.

This leaves me with my final comment about the Business Model Canvas; It is a model that needs to be revised, once every so often you need to reconsider its contents. Do it periodically, once every 6 or 12 months, but also do it when you've come to a pivot-point and realise you need to adjust your strategy, your vision or maybe even your mission. So make sure that you will maintain your BMC to keep its relevance.

I think all the above make sense, if not drop a comment and tell me what's not making sense to you. But if it makes sense, why do I hardly see a BMC print-out on the walls of offices? Why is it that so often there's no business model canvas even made? Probably there're three explanations.

  • The existence or validity of the Business Model Canvas is unknown.
  • It is considered too hard or too confrontational.
  • It is considered a management only thing.

Whatever the reason is, you've come this far, now understand what it is and that it is beneficiary for the complete organisation. And it isn't that hard to create this most important canvas for your office walls. In addition, the canvas helps you to create a sustainable business.


Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

PS: Here's an interesting link to a more elaborate BMC picture.

[Special thanks to my amazing wife, who took the time to not only read the post but to also send me a Whatsapp with a whole list of corrections the post needed. Thanks dear.]

Disruptive creativity is in the 3rd third

The 3rd third approach assumes that you want to have some creative thinking for example to fill a business model canvas, to come up with a new product, or just to become disruptive. The 3rd third approach is an approach to help yourself or your team to become truly creative up to a point that you can be disruptive.
Especially when you're a startup in a commodity market, or at least an established market and you have found a means to become a player as well, you need to be disruptive. Having said this, when you're established or even market leader, you need to make sure that you will have a competitive advantage. The third-third approach helps in that it implements a process that weeds out all the usual suspects in creative thinking.
The complete management team should be in the workshop because they need to not only understand what the business model is, but also why it is the way it is. And understand everybody's input. Furthermore, all areas are related to each other.
The approach means that when you have to come up with ideas, you timebox this idea-flow in three periods of about 5-10 minutes with in between at least 5 minutes but preferably 10 minutes where you take a coffee, have a smoke if you need it, or take a bathroom break. Or answer a call, although I prefer not to make that call until after the third timebox. During each timebox everybody writes down as many things that spring to mind about the topic at hand. Once the timebox is over, there's time for pause. The second timebox is exactly the same, but every idea already on the table is off-limits. So you'll need to come up with new ideas. The third timebox is a repetition of steps.

In my experience it makes sense to have a facilitator in the room who keeps track of the time, ensures that there're plenty post-its and sharpies in the room. Who sees to it that everybody is drinking sufficiently and who makes sure that there're energy bars and fresh fruit available. During the breaks the facilitator makes sure that all written down ideas are easy for everybody to read, even to the point of recreating the post-its in a readable handwriting. The facilitator should not be involved in the creative process.

As you'll notice when you take this approach, the each timebox will be harder when it comes to generating ideas. Especially when you've never thought about the topic before. But the wonderful thing here is that the most outrageous and therefore most likely disruptive ideas are created in the third timebox. There're the ideas of value, otherwise revert back to the first timebox after considering the second timebox. It should be worthwhile to look into the ideas written down in the third third and see if they're feasible. They might seem too outrageous at first, but then again, that is probably the sole reason why they will be disruptive; Nobody had thought of them before. So feasibility might very well be the way to increase your business' value, market position, or relevance.


Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist.But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

March 19, 2017

This is why the Dutch make the best Chief Architects...

Summary

Last Wednesday the Dutch had to perform their civic duty and vote. You may or may not have read about it, but it inspired me to post about why the Dutch make such awesome IT architects, and why your Chief Architect should be Dutch.
Having a Dutch Chief Architect, or even just architects, in your organisation will ensure that there's going to be synergy. That you'll be able to benefit from something like a collective mind. That you will have a strong person that is able to bridge gaps in culture and break through language barriers.

Why the Dutch are the best architects out there...

... Last Wednesday the Dutch had to perform their civic duty and vote. You may or may not have read about it, but it inspired me to post about why the Dutch make such awesome IT architects, and why your Chief Architect should be Dutch.

I could end my post right there, because I mean, it's obvious isn't it? But just in case you're not too familiar with the Dutch let me explain.

First of all, architecture and being an architect is all about communication. It's about explaining what you want to achieve and why you want to achieve it. And the trick here is that the architect needs to ensure that there's buy in throughout the organisation in such a way that everybody is not only on board, but also convinced that it is the right direction in which the architect wants them to move.
The Dutch do this by nature. It's an essential part in the Dutch culture to work together and get onto common ground. The Dutch call it "Polderen". It's a Dutch trait, and only the Dutch know how to do it.
Here's the deal, with the latest election results, it's very thinkable that it will take up to 4 different political parties to form a coalition that has a majority in the parliament. And the Dutch are not worried at all, because we're confident that although the different factions have very different believes, they will be able to work something out and rule the country. Form a government.

What the Dutch can do as part of their culture, an Enterprise Architect, and a Chief Architect ever so more, will need to do as part of their role. Get common ground, work with different powers within an organisation and ensure that the whole of the organisation will achieve its goals, meet its objectives, work together to implement the strategy. Who better than a Dutch architect is most suitable to perform this Herculean task?

But wait, there's more!

Chances are that when your organisation has enterprise architects and a Chief Architect, your organisation will be fairly large and will have employees, vendors and customers from all kinds of backgrounds. Could be different ethnic backgrounds, different religions, different nationalities, different everything. Working with all these different people with different views, cultures, languages, etc. will be a challenge.
Again, the Dutch will be able to fit in immediately and work with them all. For one, the Dutch speak a variety of different languages. Of course they'll speak Dutch, but English will be there covered as well. And very likely they'll speak German and French as well. More and more Dutch children learn how to speak Spanish or Chinese in school. But on a linguistic level, you're covered when you're dealing with the Dutch. In addition, hardly any of the TV shows are dubbed, instead they're subtitled, so you can be sure that that Dutch architect you're now thinking about will understand the nuances of your languages, a fair amount of slang and sayings.

What's more, ever since the Catholic church started killing people because they didn't agree with how the Pope thought how life had to be lived, the Dutch took in those that fled from the Catholic raids and Inquisition. And more importantly, the Dutch embraced all these different nationalities, religions and cultures as part of the Dutch society. Not always without a fight or without amendments, but nevertheless, Dutch culture is to embrace other cultures.
Now think about different cultures within your organisation. For one you most likely deal with employees from all over the world, or at least different religions, upbringings and the like. But there's more. You must have noticed that those people from accounting think rather differently from them from legal, and the sales people are slightly different then the people working in IT. Still in IT itself you've got the developers and the operators that are different. However you look at it, you need somebody at the helm that you can trust with knowing how to deal with different cultures, mindsets, objectives, manners, languages and vocabularies. Who else than the Dutch architect can take this task upon himself?

Obviously the architect is all by himself, even when he's the Chief Architect, he'll be the minority. He'll be the few among the many. Heavily outnumbered. Under normal conditions, that might be a problem, but not when that Chief Architect is Dutch.
The reasoning behind this statement is quite simple. The Dutch know how to rule the world. Until not that long ago they ruled together with the British the Seven Seas. They, the Dutch that is, managed to become a global player although massively outnumbered.

Finally, the Dutch don't take anything for granted, but more importantly, they're a people that don't take just anything at face value. Instead of just mindlessly following orders, the Dutch will use their head and will stubbornly refuse to do something that doesn't make sense.

Having a Dutch Chief Architect, or even just architects, in your organisation will ensure that there's going to be synergy. That you'll be able to benefit from something like a collective mind. That you will have a strong person that is able to bridge gaps in culture and break through language barriers.

So yes, I think it's clear. The Dutch do make the best Chief Architects.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist.But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

March 15, 2017

"We develop our frontends in Angular" is not an Architecture Principle

Did you ever hear that story about that architect who was telling the developers how to develop their solution? Badabing, badaboom!!!

Yeah, I know it’s a bad joke, there’s no laughter there. I better not aspire a job as a standup comedian. Thing is though that there’re still plenty architects out there that are not only defining architectures, but also tell the developers how to develop that architecture. It amazes me why this is the case.

I know that not that long ago I told you to ditch your architects when they are busy creating roadmaps. But actually you shouldn’t because there’s a real legitimate reason for defining roadmaps. The reason being that they’re an excellent tool. So ditch the architect when roadmaps are what they deliver, because those are the ones you want to get rid of.

Now there’s another breed of architects out there that I have a hard time to understand. I really think that architects should be architecting. That’s what their roles are, just like developers should develop. People should be doing what they’re supposed to do, and preferably spend some time outside their boxes while thinking about what their job really is.
For an architect, the sole raison d’etre is to have answers when asked questions and at the same time be enigmatic. Well, maybe that last part should translate into being helpful to whoever is asking the questions to get the answers themselves.

The architect, as I see it, is the one that defines the boundaries within which the developers can act freely while being confident that there’s no harm to the overall integrity of the enterprise or the organization for that matter. The strength of the architect, the real power, is that this can be done by defining Architecture Principles. These are extremely powerful because you can link them directly to your organisation’s mission, vision and strategy. Well if you can’t than you should reconsider your principles. But if you can, you’ve got your business justification for your principles and you won’t need to define the business value of those principles either. But just like any power-tool, they’re not trivial and to formulate the right principles you really need to be ready to spend some serious time. Furthermore, you need to limit the amount or principles to a maximum of 10, just like the 10 commandments. More will be hard to remember by heart and live by, which is what you should expect from your developers. Less is better, but beware of the fact that you should cover all the important bases in your environment.
There’s another tool that’s really powerful, which is the reference architecture. Which in fact is a model, one of the good kind as you can read here. A reference architecture is a model of an application that meets all the architecture principles. But beware; It’s a model, not an architecture! It’s a visualization of what the architect had in mind when he defined the set of architecture principles. And more importantly, it’s one of many possible models.
So as the architect defining the reference architecture you should be aware that everything in it, can, should and will be taken with a grain of salt. And as the developer you should understand that the reference architecture is just a tool for your architect to illustrate what was meant by the architecture principles, and definitely should not be taken literally.

Ah, so what about the joke, the bad one?

Well, there’s this group of architects that don’t understand the difference between architectures and models and instead of defining architecture principles and reference architectures, they tell the developers what and how to develop such that they comply with the principles.
There’re some serious problems here. For one, the architect omits the definition of architecture principles for whatever reason. Likely because it’s too hard, or they don’t see the benefit. Shame on them! Then there’s the case where the architect ignores the fact that the developers are very likely more proficient in developing than the architect. Oh, and let’s not forget about the fact that architecture principles are almost timeless, or at least stick around quite a bit longer than the typical technology, tool or framework. Yet, this architect dismisses this simple fact of IT and at the same time doesn’t keep the construction manual, because that’s what it is, in line with the current state of IT affairs.

For example, I discussed a couple of years ago, where ‘discussed’ is a euphemism for ‘verbal fighting’ with some fellow architects in some kind of architecture board that it made no sense to dictate that a multi-tier architecture should always be deployed such that each tier should be on separate infrastructure. Instead the application should be complying to the fact that data access logic not to be mixed with business logic nor with presentation software. Sometime ago I had a discussion, which was a real discussion, about whether or not we should define in reference architecture that either Eclipse or Visual Studio should be used for coding. Uhm, I think not, thank you very much. And yes, this was a real discussion.
There’s the discussion about what part of an application is developed in what programming language? We had the discussion at a startup I was Chief Architect at. Guess what, the developers made those decisions, I just stated the principles that I wanted them to comply with.

So what it actually boils down to is that architects need to govern, and that should take up most of their time. They should safeguard the integrity of an organisation’s IT landscape and make sure that in all cases the applications or rather the products in that landscape can comply with the architecture principles. The architect should promote and facilitate an unambiguous way of working among teams. The architect should also be concerned about an ubiquitous vocabulary within the organization when it comes to business and that it is translated by IT consistently.
The architect should not dictate that a particular programming language to be used, that a particular infrastructure is to be deployed to or that specific tooling is to be used. And in those cases where there’s a good reason for the architect to do this anyway, than it should be implied instead of explicitly dictated. In case all development is to be done in Java, the architect should ensure that only Java developers to be hired. In case everything should be hosted on Amazon AWS, the architect will have to pave the way for the teams to use Amazon AWS, making it the favorable option for the teams of the many hosting alternatives they can choose from.

As you might have guessed here, is that the architect I’m referring at is the enterprise architect or domain architect. Definitely not the application architect or the solution architect. The latter are both very much there to device a solution for a problem. They’re more like designers than architects in that sense. Which brings me to another little piece of personal amazement. Why are there so many large organisations that have domain architects on enterprise level whose domain has nothing to do with the business, but are strictly technical? Probably this is some remnant from the time that we considered IT to be a cost center and centralization of IT was the holy grail for many a CIO. Nowadays where we see IT as a product, something that is not just setting us apart from the competition but an actual product, there’s hardly any room for the these architects, at least not on an enterprise level. They should be working closely with products teams from the same product portfolio. Become Product Portfolio Architects, safeguarding the integrity of the IT landscape of the portfolio. Is it a demotion? Definitely not, it just means that they’re relevant again.

To paint a little context here, I’ve been that architect I’m complaining about. Emphasis on ‘been’. I enjoyed the technology too much to let it go, but as the domain architect I wasn’t allowed to work on the software, so all I had was telling the developers what to type. Initially I got away with it, because I was at least one of those architects that actually could still code. But really soon thereafter it became apparent that I hardly had enough knowledge or experience to really do the work. To me that was a real eye opener and I had to good fortune I was working with people that didn't hide the truth from me. They expertly conveyed to me that yes I was more than a decent architect, but as a programmer I really wasn't up to it anymore. And as much as that hurt at the time, it allowed me to focus on architecting. I still code, because I still think I need to be able to understand and to know that things might work. But as an architect, especially in an agile world I find myself more and more facilitating, communicating and coaching. Working 3 sprints ahead of the developers, not because I'm that a fast thinker, but because being an architect I need to be able to set directions. Let the team worry about how to get to our destination, be their own satnav system, and me the architect am more and more the person controlling the system's settings. Controlling whether or not to allow ferries, toll roads, to prefer back roads, go for the scenic route or the fastest or most economic route.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist.But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

March 9, 2017

Principles of the API-First paradigm

API's are weird puppies. They've been around since forever and whole battles have been fought in courts to gain access to API's. This was in the old days when having a platform with an API for 3rd parties to develop for your platform meant that you had a lot of leverage over those parties. Not providing early access to them meant that they would be late to the party and all the sweets where already shared between the early guests. Having an API meant having power. Not providing access to your API resulted in lawsuits because you were a monopolist, using your position as the platform owner to bully your competition into obliteration.

Nowadays the situation is completely different. Having an API means having a future. Nowadays to survive as a business you need to have a platform, which in turn means you need to have an API. Unless you have an API, one that suits the needs of 3rd parties and that is easy to use, you're doomed. You'll be just an Application Vendor, and toast before you can say "I wish I had built a platform". An excellent book on the topic is "The Age of the Platform" by Phil Simon.

As you can read in my previous post, API's are the hardest thing to develop. It always helps to have some guidance when you're up for a difficult task, and often principles help you getting this guidance. There're quite a few other guidelines out there on the interweb that are more than helpful. Below are 5 principles of the API-First paradigm. Followed by 5 derived principles and at the end of the post, I'm listing a couple of more than interesting resources on API design.

One final note before I go into the principles. An API is not much more than an interface into the depths of your platform. It discloses your platform and makes it possible for others to leverage it for their needs. It is therefore critical to have comprehensive documentation for your API. Now comprehensive doesn't mean that you need a big fat document describing everything you can think of that might be remotely related to your API. Typically you will need to document the technical interface of the API, i.e. the call signature of the API, including the input and output parameters of the API.
In addition you will want to document it's behavior exhaustively, i.e. only develop the behavior your documentation mentions. It makes perfect sense to use BDD (Behavior Driven Development, see my post on the topic) for this purpose. By doing so, your users know exactly what to expect from the API and it allows them to create stubs that behave the same as your API without the need to have access to your API's implementation. Finally it helps to have a simple example on how to use the API without making any assumptions as to why one would use the API. This could be through showing the relevant cURL statements.

Enjoy your reading…

Principles of the API-First paradigm

The API is the product.

It is owned by a product owner, and the responsibility of a product team. A team is responsible for it, from cradle to grave. This team is responsible for managing and ensuring its proper operation. Don't consider an API as part of another product, something that's a by-product, because it means that you won't treat it with the proper dignity and soon you'll find yourself alienating from your users.

The API makes no assumptions about its Consumers.

It is robust and resilient enough to thwart of any consumer with bad intentions as well as ignorant ones that have no clue about what they're doing. All this without compromising the service level to all well intending consumers. Mind that in most cases you're working on an API while making assumption as to who and why they'll use your API, only to find yourself in a situation where your users are all but the ones you envisioned, and all using your API for completely different reasons than why the API was created in the first place.

The API is suiting the needs of the Consumer

The API is developed only when there is at least one consumer and it is tailored to suit this consumer, by this the API is creating business value through its consumer. Don't be so arrogant to develop something that's supposed to be an API without having at least one consumer lined up to actually use it and tell you how great it is. Apart from the fact that working on something that is not being used is a complete waste of time, it also means that you're not really understanding the fact that you should not make any assumptions about the API's consumers. No assumptions at all.

The API is built to last

An API is never breaking compatibility with its consumers, although it may rely on the paradigm of 'Ignore what is unknown' to allow for extending the result. API's, other than the humans that build them, never break a contract. Period! This is to say that they will respect contracts, will have addendums to the existing contract, or in those cases when the API, which is after all a product, is no longer adding value, they will void the contract, but obviously respecting the contractual notice period. On a side note, it is fair to assume that its consumers abide by the convention that they'll ignore what they don't understand or know, hence the fact that you can add addendums to existing contracts without actually breaking the contract.

The API is idempotent.

At all times, in any situation, always. It doesn't matter what you do, how you do it or when you do it, when you call an API it always behaves exactly the same. Meaning that its result is always the same and therefore perfectly predictable. The order in which API's are called doesn't matter, as long as you put in the same values, you will get the same results.

Architecture principles for the API

The API is clear in its error reporting

Errors are either caused by the API implementation, the API consumer or something unexpected. It makes perfect sense to stick with the conventions of HTTP errors, why invent something new, when the existing is fitting your purposes perfectly. But whatever you do, make a clear distinction between these three causes for errors.

The API is always managed.

An API can be managed independently from;
Technical level, i.e. it can be accessed securely and consistently throughout its lifespan -> Scalability, Availability, etc

Application level, i.e. consumers can use the API based on a published interface that is behaving per this interface -> Interfaces, authentication/authorization, etc.

Functional level, i.e. users of the consumer can be provided access to the API based on the agreements made -> Throttling, metering, monitoring and reporting, etc.

The API can be implemented independently of its interface;

They are truly decoupled. Multiple implementations can co-exist and determining which implementation to choose for each individual call can be context driven. Mind that the interface should be technology agnostic, or at least as much as possible, and in no way should the interface disclose anything about the implementation other than that it should explain how it behaves.

The API is technology agnostic.

The interface can be called by a consumer of any technology without any assumptions of the technology used in the API implementation, and vice versa. This is pretty much an extension of the previous principle, but important enough to mention explicitly.

API's are like dogfood.

The API is used by the team responsible for it in the same use cases as the consumers for which the API was intended; "Eat your own dogfood" paradigm. Always make sure that in case you need functionality that one of your API's is providing, you're calling that API yourself and making yourself dependent on the API. Only this way you understand your API, and more importantly you'll be very cautious about how you treat your API and therefore how you treat its users. After all, you'll be one of them.

Interesting Reading




Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist.But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

March 1, 2017

The Arc-E-Tect's Predictions for 2017 - Agile and WaterfalI [10/10]

The Arc-E-Tect's Prediction on Agile and Waterfall

It's 2017, meaning 2016 is a done deal, and most of my predictions for 2016 I made about a year ago and never got around documenting in any form have proven to be absolutely bogus. Which leads me to come up with my predictions for 2017 and properly document them. So continue your effort reading this post and hopefully you'll enjoy reading them. Unfortunately we'll have to wait for about a year to find out to what extent I got it all right, but for now, ...Agile.

Why Agile? Because in 2017 we finally realise, well that big upfront design and waiting for everything to be done before release is really a dumb idea that no one with a shard of a mind can think to make sense. And all the big fat waterfall projects that were worked upon are done about now.

Agile in, Waterfall uhm... also in

Well, agile is finally in and is going to replace waterfall projects in those organisations where there is an active movement towards agile. Which nowadays are the majority of enterprises. These organisations are heavily invested in dropping the traditional practices and adopting new, more business value oriented practices. It has taken a while because these organisations also had large waterfall projects that, practically, had already progressed towards a situation where migrating towards agile was just not viable. Now that these legacy projects are close to be completely done, we see agile picking up massive speed.
But then there are still quite a few organisations that are vested into waterfall. This could be because of practical reasons, for legislative reasons that still require big releases. Or because these organisations have only learned how to talk the talk, but never went as far as to learn how to walk the walk. And this is unfortunate but still reality of the day.
In 2017 we will still see massive projects with Prince2 cycles, large upfront designs and maybe execution in sprints, but nothing like doing releases as soon as something is releasable.

So in 2017, agile will be truly in, across the board. But having said that, waterfall will still be in as well.


Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link to my blog to all your Whatsapp friends and everybody in your contactlist. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect