The Arc-E-Tect predictions for 2017 - In hindsight [2/2]

Last year, like every year, I did some predictions on what would be in and what would be out in 2017. But unlike other years, last year I actually posted those predictions on the internet.
Before I start with my predictions for 2018, I will go back to my predictions for 2017 and see how things turned out.
This is part two, and part one you can find here.

#6: KVI in, KPI out

"Forget about performance. Performance, in the end, means nothing when it comes to an organisation’s bottomline. What matters is value. However you want to cut it, unless value is created, it’s not worth the effort. And by value being created I mean that the difference between cost and benefit increases."

First prediction that I am looking at in this post is a bust. Although more and more teams and organisations are transforming into agile adopters, the value driven aspects of agility is still undervalued by most. I hardly come across organisations, departments or even just teams where success is measured in terms of realised value. Vanity metrics are pretty much still the norm. It's a shame because it also means that the promise of applying agile concepts are still a long way from being realised.

#7: Products in, Projects out

"It shouldn't surprise you, but I'm not a big proponent of projects and instead love to see it when organisations switch to a product focused approach. But in 2017 it will turn out that I'm not the only one."

This is happening big time in a lot of environments I've been in. The main reason why organisations transition from a project perspective towards a product perspective is because of CI/CD (Continuous Integration/Continuous Delivery). With reduced cycle times as a result of automation of the software delivery process, it is almost impossible to not release a product early and keep on working on it. Hence, delivery to production does not result in the end of a team.
My main concern in these situations is the lack of a Product Owner who has mandate over scope. The Project Manager typically does not have that mandate. It is the next step.

#8: Heterogeneous in, Homogeneous out

"In 2017 we’ll truly face the uprising of new and more technologies, concepts, architectures, models, etc. And in order to be able to manage this we will finally understand that we need to embrace the fact that our environments consist of a multitude of everything. In many smaller organisations that are at the forefront of technology and that are working in agile environment it is a given, but now that large organisations have also set out to adopt the ‘Spotify’ concept and thus teams have a huge amount of autonomy, polyglot is key."

Yes! Most organisations have dropped their need for huge standardisation efforts. Instead I see that architecture principles are becoming highly popular. With that and the gradual move towards autonomous teams I do see a shift in mindset where homogeneous environments is no longer considered the answer to all IT problems. This is also a mindset shift from efficient towards effective.

#9: Activities in, Roles out

"The thing is, we’re moving, as an industry, in the direction where we want be able to get feedback as early in the process as possible, which means that every person concerned with creating and delivering a products will be involved in everything needed to create that product and ensure that it works as intended and more importantly as needed. In this setup, everybody is what we in 2016 called a full-stack developer."

In 2017 this didn't happen. The T-Shaped employee and the Full-stack developer are found in small organisations. Large enterprises still have a culture based on decades of functional hierarchies. Contracts are still based on roles where T-Shaped and Full-stack have yet to find their spot. Unless agile transformations are no longer considered to be merely an IT and even just a software development thing, it will become very hard to get into cultures where teams are considered to be the atomic entity in product development and instead of roles and responsibilities, tasked are performed as activities.

#10: 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."

In 2017 I saw more and more organisations realising that the typical waterfall projects can actually be done in agile ways. This notion is actually causing the existence of waterfall to be questioned. Do we still need waterfall? No, not at all. But we still need large projects. In 2017 I saw a realisation by many managers as well as architects that large project and waterfall are not different words for the same behemoth, instead there is no a clear tendency to actually do large projects by applying agile practices and waterfall seems to be relegated to only tiny projects. Ironic, but pretty awesome.

This was part two of a two part on a quick glance on my predictions of 2017. Yesterday, I have posted part one of the series and see about how the first 5 predictions turned out. Next week will be about my predictions for 2018.

I hope you enjoyed this post. 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 contact-list. 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

The Arc-E-Tect predictions for 2017 - In hindsight [1/2]

Last year, like every year, I did some predictions on what would be in and what would be out in 2017. But unlike other years, last year I actually posted those predictions on the internet.
Before I start with my predictions for 2018, I will go back to my predictions for 2017 and see how things turned out.

#1: Microservice in, SOA out

"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."

With a massive transition towards agile practices and organisations embracing scaled agile frameworks, it has been inevitable, the Microservice Architecture (MSA) has been broadly embraced. Or has it?

In 2017 I've seen that those organisations that require true agile concepts in practice in order to be(come) sustainable also embraced MSA as the architecture of choice. The change in mindset that is required for MSA to thrive in an IT landscape and an organisation itself for that matter turns out to be more encompassing than mostly thought. I've seen it fail in those organisations that merely do agile, and succeed in those situations that are agile. Yes, MSA and Agile are going hand in hand.

#2: 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."

Here I can be short: There's hardly any talk about web-services anymore. It's all about API's nowadays and that has been the case for the better part of 2017. Over the course of 2017 the notion of API's also shifted from merely glorified web-services towards true business services.

#3: 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."

Unfortunately this prediction didn't come true at all. Although it depends on how you look at it. In 2017 I've been in more discussions than before about Application Architectures, although in most cases people were actually talking about models. I guess the terminology is out of vogue, but a lot of architects still have a hard time to use the correct terminology. Still, to me the Application Model isn't out and the Application Architecture isn't in. Just yet. Probably with a more widespread adoption of MSA, we're bound to ditch the model and embrace the architecture.

#4: 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."

This so turned out to be a correct prediction, and like I envisioned, one of the main drivers has been security. And the lack of it, in many cases.

In most environments I've been working in and with over the course of 2017 there was a real notion that no longer was it affordable to not consider security on an application level and assume that applications could be accessed from the internet. Even when that wasn't supposed to happen. Finally we know that assuming the network to be secure is an assumption that really does make an ass of u and me (assume -> ass-u-me)

The good if not best aspect of this is a security-by-design mindset in most if not all people involved in product development.

#5: 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."

In 2017 it turned out to be not that short, unfortunately. What I've seen happening is that unless agility is a true business concern, a matter of business sustainability, DevOps is not something organisations want to embrace. Although this is primarily a matter of large enterprises, those with seemingly enough money in the bank to linger a while longer before feeling the need of being able to wart of the threads of start-ups and their agility.

This was part one of a two part on a quick glance on my predictions of 2017. In the next couple of days, possibly tomorrow, I will post part two of the series and see about how the remaining 5 predictions turned out. Next week will be about my predictions for 2018.

I hope you enjoyed this post. 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 contact-list. 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

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

The Arc-E-Tect's Predictions for 2017 - Activities and Roles [9/10]

The Arc-E-Tect's Prediction on Activities and Roles

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

Why Activities? Activities because we’re breaking down silo’s in 2017 and expect people to work in teams with responsibilities become team concerns. Consequently, we’ll see less explicit roles, more implicit roles and activities shared and distributed within teams. Roles? Where we’re going, they have no roles.

Activities in, Roles out

The thing is, we’re moving, as an industry, in the direction where we want be able to get feedback as early in the process as possible, which means that every person concerned with creating and delivering a products will be involved in everything needed to create that product and ensure that it works as intended and more importantly as needed. In this setup, everybody is what we in 2016 called a full-stack developer. Concerned not only with developing the software, but also with developing the infrastructure it needs to run on. Or the other way around, not only concerned with setting up the infrastructure on which the software is going to run on, but also with creating that software.

And on top of that, the whole team is about creating value for the business, determining the right level of quality and more importantly ensuring that that level of quality is part of the product. Meaning that everybody tests, tests and tests some more. Not because testing is a step in the delivery process, but testing is part of the product creation process. The same goes for other areas. For example security and compliance is no longer something that is considered an afterthought or something that is moving along in the sidelines, but instead is an integral part of the product. The DBA is no longer a separate role, but instead the team will ensure that tuning of the database is an activity everybody partakes in.

What does this mean? It means that we don’t have a tester anymore, yet we’ll be testing more than ever. Not because we’re more insecure or self-conscious, but because everybody in the team will be testing. Or rather will ensure that the product is tested. Same goes for the security officer and the security architect. They’ll still be there on an enterprise level, but instead of doing their magic to the products, they will define risk and policy and principles and the team will ensure that the product complies to all.

Team members will get an implied role because the show the most affinity or expertise in some area and rely on others in other areas. But everybody will be responsible and accountable to perform activities instead of assuming a role.

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

The Arc-E-Tect's Predictions for 2017 - Heterogeneous and Homogeneous [8/10]

The Arc-E-Tect's Prediction on Heterogeneity and Homogeneity

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

Why Heterogeneity? Because homogeneous environments are a fraud as you can read here.

Heterogeneous in, Homogeneous out

In 2017 we’ll truly face the uprising of new and more technologies, concepts, architectures, models, etc. And in order to be able to manage this we will finally understand that we need to embrace the fact that our environments consist of a multitude of everything. In many smaller organisations that are at the forefront of technology and that are working in agile environment it is a given, but now that large organisations have also set out to adopt the ‘Spotify’ concept and thus teams have a huge amount of autonomy, polyglot is key.

Of course the irrational drive to create a homogeneous environment in every aspect was completely unsustainable, but 2017 will mark the turning point for this endeavour. ‘The best tool for the job’ instead of the ‘hammer for everything’ approach has turned out to be the best approach to solving problems throughout history and across industries and finally IT is picking this trend up as well.

An important aspect here is the fact that centralised IT is no longer a viable option for those organisations that need an agile business. A stronger and clearer view on what within an organisation’s IT is actual commodity and what isn’t will be supporting this. Yes, standardising on an Office suite and a particular version of Microsoft Office at that, makes sense. But even when it comes to IT very close to the user, say their devices, requires us to embrace the concept of polyglot.

With BYOD (Bring Your Own Device) finally becoming the norm, it is even from the user perspective no longer a matter of standardisation. IOS, Android, Windows 10 and other platforms are replacing the Windows desktop. This is possible with the Cloud becoming the platform of choice and SaaS offerings becoming pervasive. Business differentiators, the IT products that sets organisations apart, are no longer tied to specific infrastructures, technologies and architectures. Instead, they’re now treated as business differentiators, needed to create the value for the business. Sometimes because the business needs to be the first with the product, sometimes it needs to be the best among the competition. Whatever is needed, no homogeneous environment will be able to provide either in a sustainable manner.

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

The Arc-E-Tect's Predictions for 2017 - Product in, Project out [7/10]

The Arc-E-Tect's Prediction on Products and Projects

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

Why Products? Because products are supposed to outlive the projects that created them and 2017 we finally see that value creation is the sole reason why we do IT.

Products in, Projects out

It shouldn't surprise you, but I'm not a big proponent of projects and instead love to see it when organisations switch to a product focused approach. But in 2017 it will turn out that I'm not the only one.

The main difference is that we'll see IT as a product and we'll be delivering products to users. We might be doing this in projects, but organisations will switch from a project oriented organisation towards product oriented organisations. The main impact will be organisational. Of course, but organisations are (becoming) ready for this. For one teams will become responsible not only for the creation of solutions in a project, but also for operating those solutions. There won’t be a developer and an operator in those teams, but people doing both. These teams will be responsible for the products they create. That’s a responsibility towards the user. Secondly the these product oriented teams will be considered business teams as they are creating business value with the products that are developed. Accountability for the success of the products in a business concern. Mind that in 2015 we already started to consider security and compliance to be business concerns and not an IT concern. In 2017 we’ll start to see the success of our products and not only its security, to be a business concern as well. The gap between IT and business will be benign.

I can be short about projects, they won’t disappear in 2017. There will be more than ever, but their impact on the business will be less interesting from this year forward. As the overhead of doing projects is increasing almost exponentially because of all kinds of reporting requirements, there is a necessity to increase the size of projects in order to make it worth our while to run a project. This is spiraling out of control and to put a hold on it, we’ll see organizations drop the heavy duty control mechanisms like Prince2 and adopt extremely lightweight governance structures in place, which in turn requires tiny releases, often. And this puts it all in place to develop products feature by feature. Hence… Products in, Projects out. Which automatically means that the Product Owner will be the hero of 2017 and the Project Manager is no longer there to save the day, something that can be read about in another post.

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

The Arc-E-Tect's Predictions for 2017 - KVI and KPI [6/10]

The Arc-E-Tect's Prediction on KVI and KPI

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, ...Key Value Indicators.

Why KVI's? Why Key Value Indicators? Because we all work to increase our business' value. Empowerment and autonomy of teams invalidates the role of KPI's and instead teams are judged by the value they create and not the costs that they incur.

KVI in, KPI out

Forget about performance. Performance, in the end, means nothing when it comes to an organisation’s bottomline. What matters is value. However you want to cut it, unless value is created, it’s not worth the effort. And by value being created I mean that the difference between cost and benefit increases.

So unless a KPI is expressed in terms of how much value is being created, it’s highly questionable to judge a team or an individual by this KPI. In fact, if you take LEAN seriously, you should be aware that in many situations it will be the case that no performance will create more value than some or a lot of performance. In many cases, KPI’s will result in the creation of waste, of shelved products.

So what we will see in 2017 is that teams as well as individuals will be judged not by their performance but by the value they create. By KVI’s instead of KPI’s. This will be in conjunction with an increased level of autonomy and a management style that revolves around empowerment. There will be a framework, an architecture defined by principles, defining the boundaries within which a team can operate freely such that they will be able to meet and exceed the agreed upon value that will be created by them.

A key aspect in this whole new way of thinking lies in the fact that we start thinking in terms of products instead of projects and that teams will be held responsible for these products from cradle to grave. Product Owners, DevOps and Product Teams are the new trends in 2017 and that allows us to drop the questionable KPI in favor or the real metric: KVI.

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

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

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

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

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

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