Translate

January 27, 2017

The Arc-E-Tect's Predictions for 2017 - DevOps and Scrum [5/10]

The Arc-E-Tect's Prediction on DevOps and Scrum


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, ...DevOps

Why DevOps? Because finally IT is considered a money maker instead of a business enabler. And it's about time.

DevOps in, Scrum out

I can be very short about this. Business has finally come to understand that IT is not something that enables them to deliver new products to their customers but instead IT is what they deliver to their customers. IT has become a product, and therefore an immediate business concern.

Gone will be the days that there is a clear separation between business teams and IT departments.

But before we get there, we need to get rid of the silos between development and operations. Ever shorter release cycles will ensure that everybody will understand that the developer is the operator in order to sustain short feedback cycles.
Because of the short release cycles, it will be possible to 'tune' software that is already in production. Tweaking it until it is as good as needed. Less time is spend on assumed correctness and more time on proven awesomeness. This can only be done by removing all unnecessary links between the consumer and the producer, i.e. the user and the developer.

The business will be requiring that less time evaporates between explaining a new feature and starting to get revenue from that feature. A shift from 'potentially shippable' to 'in the hands of the user' as the definition of done, will mean that we stop thinking about how to create great software that is needed and usable and start thinking about how to get somebody actually using that software.

A 'Product mindset' is a prerequisite for this shift, and abandoning a 'Project mindset' comes with it. I blogged about the consequences of this here. And in 2017 we will start seeing this happening all over the place.


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

January 25, 2017

The Arc-E-Tect's Predictions for 2017 - Internet and Intranet [4/10]

The Arc-E-Tect's Prediction on Internet

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, ...Internet

Why Internet? Because we're going to move into a direction where we no longer assume the world to be trustworthy and we know for sure that our systems, services and API's are being called by consumers we know or at the least are consumers within our own organisation.

Internet in, Intranet out


So the internet will be in, and no longer will we consider the intranet as the context in which our software is running. Talk with any cyber security firm and they will tell you that security has become a real issue since computers got connected. Networks are the root of all evil when it comes to viruses and the likes. The larger the networks, the bigger the problems. And with heterogeneity the number of threats only grew, probably exponentially.
Until some time ago, and in many organisations only since a while, security is no longer a network issue anymore. Why? Because we no longer know what the network is. Meaning that maybe we think that our systems are running in an isolated LAN, but with networks and interconnectivity becoming more and more complex, the concept of a LAN is just hardware, software is pretty much always connected to the internet, if not directly, it will be indirectly.

So the notion of the intranet is no longer valid when it comes to security. In 2017 we will no longer say that security will be less of an issue, because the software is only accessible from internal systems. From the intranet.

Similarly, we will drop assumptions regarding where consumers of our services will reside. The consumer will no longer be assumed to be in the same network segment, or a segment nearby. So performance, latency, throughput, and related requirements cannot and will not be handled by assuming that the consumer is 'close' to the provider. Something we already know because we have been sold hybrid clouds by our hosting partners. In 2017 we will no longer make any assumptions as to where our systems run, our software will be location agnostic.

Then there's the matter of the user. The user is not to be trusted. Period. Which means that the user has to be identified, authenticated and authorised at all times. And we won't assume that she's on the same network when she accesses a system. That's context and we assume the worst.

So basically, what this prediction means is that we will systematically assume the worst when we develop new business solutions and create more value through our IT solutions. And to do this effectively, we assume that our systems are connected to the internet, accessed via the internet and threats are coming from the internet.

Will it make our systems more complex to develop? Probably, but only slightly. An important reason for complexity only to increase slightly is in the previous predictions. But the real benefit is that our systems become more changeable, adaptable, usable and robust. All aspects that generate value for our business, provide the software exposes the right behaviour.

One other important thing to mention here is the fact that the internet does rely on pretty cool standards, solutions, guidelines and the like. Things like DNS allows for logical addressing, REST and SOAP allow for well defined interfaces that are decoupled from implementations, resulting in real Consumer Driven Contract thinking. HTTPS is sufficiently secure means of transport, evaporating the need for VPN based solutions using proprietary solutions. Etc.

So why 'Internet in'? Because finally the intranet is out.


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

January 18, 2017

The Arc-E-Tect's Predictions for 2017 - Application Architectures and Application Models [3/10]

The Arc-E-Tect's Prediction on Application Architecture

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, ...Application Architectures

Why Application Architecture? Because that's what matters. In a world where agility, quality and security matter more and more. Where business and IT are moving ever closer together and performance is measured in value instead of function points. Architecture is what saves the day, so don't even think about ditching your architect.

Application Architecture in, Application Model out


Yes, in 2016 I've been confronted with application models. Again and again I have been slapped with models of applications and yes, I've been on the other end of the slapin' stick as well. Shoving application models into other people's faces. Stuffing it down their throats, making them, no forcing them to understand.

There're some good models out there, they're the ones that we call 'Reference Architectures'. They're good because they suck slightly less than the other models.

Models suck

What's so bad about models? Well, that's just it, they're models. We think of models because they simplify our lives. Models are an abstraction of reality, such that only those aspects of the real world that matter within a specific context, are left. That's the sole reason why we have models, because we find reality too complex to work with to solve particular problems.
Mind, models are never showing the whole picture, so they can never be used to solve the whole problem. There's always something else left to look at. Unless you are very consciously thinking about models in this way, you're in for a real treat when working with models while solving problems.
Case in point; just think about all the contradicting models that we find in all kinds of science.

Models are great for thinking. Don't get me wrong, in communicating complex concepts, it helps to discuss models because it reduces the chance for discussions on irrelevant details that are on familiar ground. Just like using analogies to explain a controversial concept. I love to use the story about preparing an egg for breakfast to explain the importance of understanding (business) processes.

Architectures rule

Architectures are representations of something to come, but unlike models, architectures have relevance because they are explainable. You can discuss a model, but not why it's a good or wrong model. When the model turns out to be wrong, you just choose another model. You can debate which model to use, but that's it.
Architectures can be explained because with architectures come principles. Principles are common truths, are more or less decisions taken by one or more persons that understand the problem at hand and are working on the solution. In addition, and that's really important, there's for each principle a rationalisation of the principle and a concrete impact on applying the principle.
Solving your problem by devising a structure, while putting the flesh on that structural skeleton using the described impact of all applicable principles gives you the architecture.

So architecture are different from models because they can be discussed objectively. One can discuss the rationale between the principles underpinning the architecture, and analyse the impacts of these principles. In addition, an architecture never leaves out any form of complexity in order to address a problem and therefore leave out the ugly pieces of the picture. Instead, architectures show the complete picture.

Why architecture in and models out


It should be clear. We need to be faster in solving problems, delivering higher quality while doing so, and include security (in all of its forms) as an integral part of the solution, while staying adequate. Not doing too much or too little, but just right. This requires that in 2017 we always need to look at the full picture, address all aspects and cover all our bases.
Models by their very nature don't do any of this, and architectures explicitly do.

The reference architecture trap

Don't fall for the reference architecture, the model pretending to be an architecture. Reference architectures are models of how we want solutions to look like. They're not architectures, because they don't represent a solution to a real problem based on rationale with known impact.
So Forrester's 4-tier architecture, which is actually a model, is out in 2017. So is the multi-architecture, the client/server architecture and the Service Oriented Architecture.
These are all models, so don't waste too much time on them. Be aware of them, understand them, put them in your toolbox when you're an architect. But whenever you work on a solution to a business problem. When you're asked to generate value, stay as far away from models and work on architectures. Don't do the big scary architecture, but the lean to-the-point-and-no-more architecture. Take note of the product backlog to understand the direction in which the Project Owner is heading to stay facilitating, but try not to disclose more than 3 sprints worth of architecture to the Product Team. 


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

January 16, 2017

The Arc-E-Tect's Predictions for 2017 - API's and Webservices [2/10]

The Arc-E-Tect's Prediction on API's


It's 2017, meaning 2016 is a done deal, and most of my predictions for 2016 (I predicted them about a year ago, but never got around documenting them 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, ... API's!

Why API's? Well, API's are all the rage and everybody and their mother is working on platforms, and as we all know; Without API's there is no platform.

API's in, Webservices out

Okay, in 2017 we'll feel ashamed when we talk about web-services and SOA. Instead we'll talk about API's. This is closely related to my first prediction on Microservices, which you can read here.

API's are basically another word for webservice to many people. So there's not much different here. Just as with the Microservices, we'll see mentioning of API's more and more where in the past we talked about webservices. Until people are referring to platforms, something that is really picking traction. Still I'm not talking about platforms, but about API's instead.

The reason for this is their strong relationship with Microservices. Delivery of a platform is a strategic decision that defines the direction in which an organisation is thinking about products. API's, which expose the functionality of a platform, are products. You can read all about this in my series on API Management on Azure, which you can find here. Other than web-services, which are pieces of functionality and/or data exposed via a well defined interface, API's are always targeted at an external consumer of the service. In other words, an API never knows who's calling nor does it make any assumptions about who's calling. Web-services on the other hand might very well be limited to a known set of consumers and make assumptions about their consumers.

The promise of web-services, predominantly a decoupling between functionalities in an IT landscape, is limited to those case where the web-service, or rather it's interface is treated as an API. API's, almost by definition, are bound to deliver on the promise of decoupling. When developed properly, taken care of and fronting independent pieces of software, API's are the closest thing to silver bullets in software we've come across so far. And since we love silver bullets, API's are in, web-services turned out to be just plain old regular bullets, so they're out.


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

January 14, 2017

API Management in Azure using Microsoft's solution - Why API's should be managed and by whom


This is a series of posts regarding the topic of API's and API Management on Microsoft Azure. Not all posts in this series are directly related to Microsoft Azure and their implementation of API Management, that is intentional. The series also explains about API's, about creating API's and about what it construes to in order to manage them, conceptually and in reality. The reason for this series is that over the past 12 months I've come across many articles on the web, have been in many discussions and advised various clients of mine on this topic. Sometimes discussing with fellow architects, other times with vendors, still other discussions where with developers and managers. But the overall situation has always been that none of the people at the other side of the table had a full grasp of what developing API's in an organisation means, what it entails to manage them or what should be worried about when deciding to go API. I hope you enjoy reading these articles, and when you feel like it, comment on the articles. I always take serious comments serious and will reply to my best effort.

I hope you've read my previous post on the topic of API Management, if not I strongly advise you to click here and read it.

Summary

Although managing API's has some resemblence with Looijen's model for IT management, the typical segregation between business and IT that stems from Looijen's model is disastrous for API management. API's need to be managed by a single team, the Product Team. Any other way of managing an API doesn't make sense. API's are products and should be treated that way.

API Management

API's are interfaces to (business) functionality that are accessed by, in theory, just about anybody. As can be read in my previous post, the idea of having API's and one of the main reasons why developing them is so hard, is the fact that you don't know up front who is going to call the API. The point in fact is that in a world of API's there is no room for the arrogance of the developer knowing exactly who is going to use the software and why. Instead, API's are inherently developed to support the case that the developer was wrong.

Because of this, when you expose an API, you'll need to make sure that you can support the API once it is deployed and used by somebody. Supporting means that you need to make sure the API is running consistently over time, the API must be usable and stay usable over time. Hence the API must be managed.
In order to do so, API's need to be managed on three different levels that to some extent relate to the support levels documented by Maarten Looijen, of which a description in Dutch can be found here. Basically he defines Functional, Application and System Management

The Looijen Model

(Skip this section in case you're not interested in the different kinds of support types.)
The model is not shocking as it states that there're three types of support that is required to support an IT system:

  1. Functional Management. [Original text translated by Google:] Functional management is the management form that includes all administrative tasks that are required in the context of the use of information systems. As usage focuses on functionality, such as entering, handling, procurement, transportation and storage of data refers to information management.
  2. Application Management. [Original text translated by Google:] Application management involves developing and maintaining applications. In the words of Parts and Looijen: "There may be many situations in which changes should be made in the original application software or database structures (...) Whenever such a situation occurs, application maintenance is performed but also.. when there is no direct reason is to perform application-maintenance, it is because of the continuity may still be required in order to maintain a complete management shape surrounding this executive task area application maintenance, including management and executive tasks. " Application management is like form, as it were about the task area applicate maintenance built around. It is to recognize application is essential that once developed information not evident also delivers the tools to easily support the change process (eg. Documentation). In addition, persons other than the original developers may be involved in the execution of modifications. Therefore it is important to maintain conditions which an application must meet so that they can be maintained 'easy'.
  3. Systems Management. [Original text translated by Google:] Technical management includes the management form all tasks necessary to install, accept and operationalize and maintain information systems and technical infrastructures. Under technical management also includes optimizing processes and making changes in the technical infrastructure as a result of errors, extension or replacement. The technical management is focused on the technical platform, consisting of equipment associated with basic software, and implementation of information systems built on it.

Management of API's the Looijen way

Now that you understand what I mean by the Looijen model, it's time to inform you how API's should be managed.

API's are to be managed on the same levels as other software, that is the functional, the application and the system level.

System Level: On the system level, API's need to be managed such that they are made available. At the very minimum there should be an error stating the API cannot be accessed. At system level you manage the infrastructure on which the API is running. This might include some middleware as well. Since API's are to be called a lot, system management also covers scaling, i.e. elasticity, as well as all kinds of resilience aspects. Also security aspects like DDOS prevention, (web application) firewalls, etc. are part of the system management aspects of API management.

Application Level: On the application level, API's need to be managed such that they can be accessed, that the API documentation, (how to call the API?), is available, etc. Basically what it means is that there is an API to be called and that the technical aspects of the API itself are managed. For example the fact that an API accepts both JSON and XML parameters, that there is an API specific certificate defined such that the caller can verify the API call is served by a trusted system etc.

Functional Level: On the functional level, API's need to be managed such that they provide some value to somebody, preferably to both the consumer of the API as the team behind the API. API's are excellent for creating win-win situations, and these are business relevant situations. Basically what managing API's on a functional level means, is that you manage the relationship between the API and the consumer of the API. Think about a consumer having to pay for access to the API and setting different thresholds to control this.

When you look at the above different levels of API management, you may have noticed that on a system and an application level, managing the API is rather technical, but on a functional level it's really a business concern. Switching back to Looijen's model and you see that he makes a clear distinction between the two as well. System and application management are technical concerns, functional management is a business concern.

What if API's are not managed?

So what if you don't manage API's? The answer is actually rather simple. It becomes irrelevant, and in the end will seize to exist. For one thing, an API needs to be kept available. When it's not available, no consumer can access it. So on a system level it needs to be managed. This is no different from any other software application. Not managing an API on a system level results in the same chaos as not managing any other software, with the side note that API's are called by any(kind of) consumer, so the 'blast radius' cannot be predicted. From this, there's no reason not to manage the API on a system level as any software needs to be managed. There's one other point to be made here, and that is that an API needs to be kept available, meaning that it needs to scale, preferably horizontally and it needs to be resilient. Both are aspects that are not traditionally system management aspects as with API's this needs to be addressed on a software level.
On an application level things are getting a little convoluted with the system level management. In fact you might already have gotten the opinion that system level management is very much like application management and in fact you're correct. But system level management is more of a 'keep the shop open' issue, and application level management is more of a 'retain customers and grow your market' issue. When customer are not attended to, they'll go elsewhere. API's need to be managed on an application level as they are called because the consumer wants to. When the consumer needs to, eventually he'll leave for a more convenient API that provides sufficient added value to migrate to it. Hence the API needs to be amended to support other protocols, other data formats, more security etc. All aspects of application level management. See this as a matter of keeping the interface of the API consistent, but the implementation behind it evolving. So the API might be providing a consistent end-point to a consumer but evolves from a low-cost inefficient implementation to a costly but efficient implementation. This is API management on application level; replacing implementations behind an interface. If an API is not managed like this, it will become obsolete at some point. Obsolete API's are useless but cost a lot.

The system level and application level management concerns of an API are clearly required in case an API to some system or information is provided. When the API is not managed on both levels, the API will become irrelevant. But what about the functional level?

Functional management of an API is addressing an API on a business level. Read the post on API first design here to understand why API development is costly and if not anything else, the most difficult thing you can do in software development. Because it's so tricky, it's important that there's a business reason to actually do API development in the first place. And this is where functional management of an API comes to the stage. This is where it is managed that an API is monitored on a business level, for example keeping track of how many different consumers are using the API, how many of the consumers are 'returning customers' etc. Functional management of an API is all about managing the metrics about consumers of the API and act on them. Consumers that do a lot of calls may be willing to pay for each call to the API, consumers from specific industries will be more willing to sacrifice some performance in order to gain security etc.
When API's are not managed on a functional level, there is no point in developing an API. API development is so complex that there needs to be a business justification to do so. And it needs to be validated that the initial justification which is always based on assumptions, is correct. Not managing API's on a functional level will ensure that funding in the broadest sense of the word, will stop eventually.

Who manages API's?

API's are managed by both business and IT. Refer to Looijen again and you see that for software solutions, managing these solutions requires both IT and business. The same goes for API's. In a traditional organisation, one that has a clear separation between business on one side and IT on the other, API's are technically managed by IT and the developer of the API needs to provide an interface to the business to manage the API on a functional level.
Further complicating the scene, refer to organisations where IT is divided into a department that is more concerned about applications and the other department more about infrastructure. In this situation system level management is done by the infrastructure people and application level management is done by the application people.

Followers of the Looijen model are typically of the opinion that Application Support can be done by system managers. The reasoning often is that system managers are technically skilled people that understand applications as they understand the infrastructure on which the applications are running. And since they manage the technical aspects of the application and not the functional parts, they're more than suitable to manage the application as well as the underlying infrastructure. This view is incorrect (click here to read why) and when it comes to API's it's disastrous.
When you have an API based platform, and there really is no other way to have a platform, you need to consider the software implementing the API as well as the infrastructure on which it is running as a single system. It makes hardly any sense to see them as two separate pieces of the API puzzle. The reasoning here is that scaling, resilience and other aspects of the system level management of the API, i.e. managing the availability of the API, is an application or software concern that leverages infrastructure which in fact could be to a great extent be software as well. Therefore API's are preferably managed on both system and application level by the same team. Consider the API as a product and we're talking a Product Team here.
The importance of an API's availability and the complexity of developing an API leave no room for any other approach than a very tight cohesion between the API implementation and the full stack on which the API is running. Both the API and the underlying stack need to be developed in conjunction.
By the way, software developers shouldn't be concerned with system level management of the API and system managers shouldn't be concerned with application level management. Either both are in the same team, or the team consists of members that understand both levels of management, a rare breed indeed.

So what about functional managers of API's? These are business people, people that understand the business behind API's as well as the API they're managing. They're not technical people at all, they understand platforms, but from a business perspective. They can see IT as a product, and they discuss IT in terms of solutions instead of technologies. They're not Product Owners, they might be the most important stakeholders of the PO on some level.
API's have an implementation and they have consumers, but there're also people that make money of the API. It's the holy trinity of the API: Producer, Consumer and Beneficiary.
Because managing an API on functional level will have its repercussions on both the application level and system level of the API, turning the functional dials needs to be done in concert with the application and system level management efforts. Therefore, functional management should be done preferably by the same team as is taking care of the application and system management of the API. Resulting in a true Product Team.

Concluding

API's need to be managed because otherwise they will become irrelevant and obsolete. In this API's are not other than other software solutions. The complex nature of API's are an additional reason to manage them carefully.
API management can be discussed using the model by Looijen on IT management as all key aspects of his model apply and the clear distinction between business and IT exist with API's as well.
On the other hand, Looijen's idea of a clean segregation between business and IT and even within IT is not a logical segregation for API management. In fact, API's need to be managed by a single team on all levels of API management; The Product Team.

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.

Iwan

January 5, 2017

The Arc-E-Tect's Predictions for 2017 - Microservices and SOA [1/10]

The Arc-E-Tect's Prediction on Microservices

It's 2017, meaning 2016 is a done deal, and most of my predictions for 2016 (I predicted them about a year ago, but never got around documenting them 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, ... Microservices!

Why Microservices? Because they're not just a hype anymore, but are moving into the realm where people are applying them because they're useful and not just cool. So my prediction is:

Microservice in, SOA out

That's right. In 2017 people will start looking at Microservices as something that is useful and way better to have in your architecture than services. So a Microservices Architecture will replace Service Oriented Architectures in 2017.

What does this mean?

Well not that much at first, until one realizes that an important reason for SOA, the DRY principle is no longer valid. DRY, Don't Repeat Yourself, is an important aspect of procedural programming that got more attention in object oriented programming and became one of the even more important aspects of SOA.
In procedural programming developers introduce procedures to have a single implementation of an algorithm or procedure. By calling that procedure over and over again instead of programming it over and over again, the developer reduces the chance for errors in the code.
Then came object oriented programming and procedures, methods, were clustered together in classes to ensure that concepts and their behaviour only had to be programmed once and used often. It's a flaky definition, but covers my intention. So re-use was immensely important for object oriented programming and this is where DRY became an important architecture principle, even a pattern.
After some time, developers started moving towards services, web services that is. In OO, Object Oriented, there's a great practice to separate the interface to a class' methods from their implementation. Depending on the programming language you use, you'll use a variety of techniques to accomplish this. In an SOA, and yes, I'm a bit short on the elaboration here, we separate the implementation of a service from the interface to access it. But the whole idea is that you implement certain functionality only once, the service, and use it from around the world. By sticking with the interface you can change the implementation without affecting the callers of the service.
So in SOA, Service Oriented Architectures, re-use is huge and DRY is a pattern.

Here come the Microservices. Microservices are not tiny services, instead they are completely self contained pieces of business concepts. They're independent of each other. They can use each other, they can rely on one another, but they don't depend on each other. That's a key principle of Microservices. It also means that if both use the same algorithm or other functionality, they both implement it. Meaning that the code is not reused! Because if one would reuse parts of the other, it would depend on it. So, in a Microservices architecture, DRY is an anti-pattern.

In 2016 everybody started doing Microservices, but actually they implemented an SOA and called it a Microservices architecture because SOA was, well, old school. An SOA has become something tainted because for one most enterprises confuse an SOA with an architecture build around an ESB and they're strengthened in their belief this is correct by the ESB vendors. Which is of course just marketing horse dung as you can read here. In addition, SOA's have hardly ever delivered what vendors and architects promised: Agility, lower costs of change and independence of clients (consumers) and servers (producers). Why? Because ESB's and by association SOA's make architectures more complex and harder to change although they hide their complexity inside the products, making them look less complex. But ask yourself: Did you ever try to migrate from one ESB (version) to another? 
So we drop the SOA and brought in the Microservice to attract new developers.

Fortunately, Microservices are hard and costly to develop and maintain. From day one. Therefore all adopters of this new and shiny architecture had to reconsider their choice to move to this new architecture at a very early stage. Realising that understanding is more important than knowing and none of the vendors had a ready out-of-the-box Microservices solutions that they could sell, the level of knowledge and understanding is already in 2017 such that Microservices will start to replace SOA's.

In 2017, companies will drop service oriented architectures in favour of Microservices architectures instead of implementing SOA's with Microservice look-a-likes.

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.

Iwan

January 2, 2017

Roadmaps are why you should ditch your architects

Summary


Architects that are not with you along the way are of no use. You should not pay too much attention to them, they're not worth the frustration they cause as nothing good will come from it.
But if you find yourself in the company of an architect that is trying to be with you all the way, you should cherish that architect and consider yourself extremely lucky. Not only because your life will be better, but more importantly because this is a very rare breed.

Classification of Architecture Irritation

In case you're interested in finally getting that excuse to get rid of your architects, you're most likely frustrated with them, their architecture and probably you are not able to see any added value of the architect in your organisation. Therefore, I think you'll most likely fit into one of these groups:
  • Your architect is too technical and strict, and that the architecture is too restrictive and technical.
  • Your architect is just the right person for the job, and a great job he's doing with that just right architecture.
  • Your architect is too high-level and vague to be helpful, and that the architecture is too high-level and vague to be useful
And in case you are an architect, you will fit in one of these three categories and your surroundings classify you as either too strict, awesome or just not helpful at all.

Now think about it really carefully... if you're the just right architect or you're dealing with that architect. Since how long do you feel that way? Has it been forever? Well, then this post isn't for you, but continue reading anyway. In case your answer is something like 'just recently' or 'since not so long', then this post is for you because there's a reason why it's been not since forever and it's bound to change in the near future. Well, it'll be very likely you'll going to move to one of the other groups.

The roadmaps are what make architects roadkill

When your architect already is one of those that you can't really consider useful, and is creating architectures that are not really helping you. Or when you're one of those architects. Well, you're in for a treat, because this is a cause of possibly the main frustration within your IT department. Or even within your whole organisation.

Now why is this?

This is because these architects only add time and costs to your projects and nothing else. They too often behave like auditors, telling you what's wrong and not how to fix it. But other than auditors, the architects refer to something they created themselves in the past, using the RTFM reply.
Auditors are a pain in the buns because they point you at how you're not playing by your own rules. Based on what your own definitions of good and bad are and what is and what's not acceptable, they'll verify to what extent you play by those rules. Architects, too often, will work on a reference architecture, architecture principles or even guidelines and that's it. You use their output to work on your own products. And you'll notice that as soon as you start using their stuff, it's either too restrictive (we develop software in either Java or .Net), too outdated (we develop our software based on JavaEE 5) or too vague (we develop our software based on the multi-tier architecture). Whatever it is, it's not helping and as soon as you ask your architect to do a scan of your products, it will be noticed that you're not using Java or .Net but NodeJS instead, that it's based on Java 8 or that it's an architecture based on SOA principles utilising a serverless infrastructure using Amazon Lamda.
So by either abiding the rules written or checking to what extent your compliant, you're loosing time and wasting money.

In many cases this is because people think architecture is a noun, while it is in fact a verb. Let me repeat that;

Architecture is a verb, and definitely not a noun!

So when you document an architecture, you're documenting a living thing. Something that is changing constantly.  So understand that when you come across a document with an architecture, look at the date of the document, because it's a snapshot of what the architecture looked like at that date. Or rather, it's likely to be the case.
But it doesn't end there, architecture isn't just some thing that changes constantly. It's an opinion of somebody who is mandated to be opinionated. What this means is that the architecture is also showing where you want to go as an organisation with your IT landscape. It's the as-is, the to-be and the route to get there. It's like a sat-nav system, it determines based on GPS coordinates where you are on the map, you enter your destination and it will calculate the route to follow to get at your destination based on your location. This is architecture. Well, part of it. The part that's relevant for this post.
That reference to driving and navigation is something I've done before. Read about it here. It's how I explain to my kids what my job is. I see where my client is, I negotiate with him where he would like to be and then come up with a plan how to get there. Including a clear definition of the impact on his situation along the way. Goods and the bads of the trip.
When you look at how many architects work, it's no surprise that they're so frustrating. The analogy with the SatNav is very clear in this;
There're those that will just hand you a (road)map and you just figure it out. See where you are, find where you need to be, plan your trip and go. And oh, btw, the date on the map is likely not very comforting. Or you'll get a turn-by-turn overview of how to get from A to B, based on the outset of when you started to plan your trip. It's based on some possibly old view of the world and any changes to the roads, terrain or otherwise are hopefully taken into consideration. But any traffic jams or other obstructions along the way are not in scope.
And then there's our trusty connected SatNav system. And the analogy holds. Because this thing is connected to the world. It not only keeps track of where you are during the trip itself, but it will keep an eye out to where you will be shortly. That won't be your final destination, but in case there's some roadwork up ahead, it will guide you past it. You'll be informed about relevant information along the way about gas stations and gas prices, hotels, restaurants etc.
The interesting part here is that those that have ever driven with a map, remember the fights between the driver and the person reading the map. Or those near death experiences when you were driving and reading the map yourself. And in case you printed that yahoo page with the turn-by-turn route to wherever you thought you were going to end up, you'll remember that all of a sudden there's a lot of places with the same name, roads are always under construction and the turn-by-turns are always irrelevant after the 5th turn or so.
These are the architects that think architecture is a noun.
The SatNav is constantly with you, and the better the system the more it anticipates on the road ahead, keeping you informed about your surroundings, distance to destination as well as the arrival time. It will keep in mind that weather conditions might be cause to divert your trip or maybe start the AC to make sure that the climate in the car matches the weather outside. This is when architecture is a verb.

Architects that are not with you along the way are of no use. You should not pay too much attention to them, they're not worth the frustration they cause as nothing good will come from it.
But if you find yourself in the company of an architect that is trying to be with you all the way, you should cherish that architect and consider yourself extremely lucky. Not only because your life will be better, but more importantly because this is a very rare breed.

Conclusion

I did already post about project managers and their demise here. Well, it's not a lot better when it comes to architects. Actually it's worse, because these architects, the ditch-able ones, are useless even in waterfall projects, but more so in agile projects, I give you that.
But where you can still find some use for most of the architects in waterfall projects, because as you know, these projects consider documentation as a key deliverable and are run under the premise that after creating the documentation for the next 12 to 24 months they don't need to change. In Agile projects this is different and this is why many scrum teams have said their goodby's to architects and even organisations have stated that architects are no longer need. And yes, this is the best thing that could have happened to our profession as IT architects. It's a matter of weeding out the turn-by-turn style and map style 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 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.

Iwan