SOA

The Idea Card

by

Whatever business you are in innovation is the name of the game. Today it’s even more important than ever that you innovate fast and somewhat accurate. This little card is designed to help you go fast by staying small and keeping it nimble. When you should use this Whenever you need to innovate When you […]

The Entity Card

by

Whatever business you are in, information is the most important raw material there is and it should be understood by many. Using tools like the entity card is one way of communicating on relatively stable information structures, there are other ways. People may say this is hard and takes a lot of time todo. To them […]

The Entity Card

by

Whatever business you are in, information is the most important raw material there is and it should be understood by many. Using tools like the entity card is one way of communicating on relatively stable information structures, there are other ways. People may say this is hard and takes a lot of time todo. To them […]

Microservices Architecture versus SOA

by

TechTarget has published another one of my “Ask the Expert” columns.  In this one, I offer up my thoughts on the differences between a Microservices Architecture and a SOA.  In a nutshell, I think the microservices trend has moved things in the right direction, a direction that many of the SOA pundits were espousing back […]

Z Ride for Hope

by

A break from my normal tech-related posts.  In September, I will participating for the second time in the Pedal the Cause bicycle ride in St. Louis.  This great event raises money for cancer research at St. Louis Children’s Hospital and the Siteman Cancer Center in St. Louis.  I filled out my rider profile in late […]

Sharing the Solution Domain Taxonomy

by

Sometimes, Enterprise Architecture efforts fail.  This is no surprise to folks in the EA business.  This failure occurred slowly, back in 2007 and 2008.  But it did occur.  It took me a while to realize it. 

I had developed a method useful for Application Portfolio Management as well as for Service Oriented Architecture called “Solution Domains”.  The method is good.  It’s a framework and taxonomy for high level descriptions of software so that generalized services can be created AND so that the portfolio of applications can be rationalized.

The method is good.  But I failed to position it’s use in the appropriate enterprise program in the appropriate way.  I failed.  Not the method.  Where we used the method, it worked brilliantly. 

I’ve learned from my mistakes, but being unwilling to let a good thing go to waste, I’m sharing the Solution Domain taxonomy with the world.  It’s not patentable (I tried).  It is useful, however, because it is a part of a business method that supports Application Portfolio Management in a completely technology agnostic manner as well as Middle-Out SOA.

I’ve put the entire taxonomy on my Enterprise Business Motivation Model site at: http://motivationmodel.com/wp/application-portfolio-management-and-solution-domains/ 

I may return here, at some point, and provide further details on how it can be effectively used.  For now, back to work!

Sharing the Solution Domain Taxonomy

by

Sometimes, Enterprise Architecture efforts fail.  This is no surprise to folks in the EA business.  This failure occurred slowly, back in 2007 and 2008.  But it did occur.  It took me a while to realize it.  I had developed a method useful for Application Portfolio Management as well as for Service Oriented Architecture called “Solution…

Microservices Unplugged

by
Given my (well-known and enduring) interest in all aspects of services, I have followed Martin Fowler’s writing on microservices. But I will admit I always found the original paper more confusing than insightful. And in my client work I have resisted the temptation to use a microservices pattern, for precisely the reason that it would more than likely confuse. So I was interested to see the book Building Microservices by Sam Newman published last month, particularly as Newman is part of the Thoughtworks stable, which presumably means it is authoritative.  

Right off the bat, Newman advises that we should “think of microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile Software development”. These analogies are very interesting because my expectation was that microservices is a pattern. So I might infer that microservices is a set of process techniques as opposed to an architectural approach. Yet in the book, Newman clearly includes some elements of concept model and architecture as well as process and organization.

Probably the biggest weakness of Newman’s book is the absence of a coherent reference model. He discusses a series of heuristics such as:

                – Microservices are small, autonomous services that work together.

                – With high cohesion.

                – Gather those things that change for the same reason, and separate those things that change for different reasons.

                – Using business boundaries.

                – How small is small? Could be written in 2 weeks; small enough and no smaller; can be managed by a small team

                – Separate entity. All communications between services are network calls. Decoupled. Minimum dependency.

                – We need to think about what our services expose, and what they should allow to be hidden. If there is too much sharing our consuming services become coupled to internal representations.

And these are mostly useful principles, but are most unlikely to guide a consistent approach. Given Martin Fowler’s involvement, I would have expected at least some good patterns. But mature SOA needs a defined concept model, like CBDI-SAE, SOA-RM etc.

This lack of clarity is fundamental. Many organizations treat operations as services, and they typically end up with thousands of services. They will be confused by the very term microservice because they already have what they perceive as small services. Perhaps the term microservice has been chosen because of the ubiquitous use of the ITIL service, which undoubtedly means monolith. Most mature SOA organizations define services and operations as a primary technique to establish cohesion guided by reference models such as SOA-RM and CBDI-SAE. Just as important is the clarity and precision around specifications or contracts and what is exposed to consumers (APIs) and providers. Yet the book contains nothing on the subject of rich service specification or contract as the primary means of achieving implementation independence and business alignment. Organizations adopting microservices will need a defined reference model. Without that there will be architecture governance by personal opinion. I wonder how Thoughtworks advise their clients in this area? 

The book contains some quite general advice on business capability based decomposition – which is a tried and tested method of defining services. However there is little or no advice on what a well-formed business capability is, it’s characteristics and governance considerations. In my experience this is an area for considerable confusion; the business capability concept is so well known, but little understood, it’s an accident waiting to happen. And as for the relationship between capability and service, there’s no model provided, and more importantly, the granularity of a business capability service is likely to be non-trivial.

Similarly there’s no guidance on types of service. Do all services contain a mix of channel, process, business and data behaviors? Which you might expect given the explicit advice to gather those things that change for the same reason, and separate those things that change for different reasons.

The one area that might be helpful is the concept that microservices are highly autonomous, and a capability cluster of services would be a unit of deployment. But sadly for Newman, this is an idea that I and my colleagues worked on and popularized nearly 20 years ago. We called it Component Based Development, and the concept was closely allied to Rich Service Specifications which enforced the component boundaries, a concept that seems to have escaped him.

Once upon a time I had expected there to be a microservice pattern. But having read the book, all I see is a set of established ideas being rehashed in a very superficial manner, under a new name; with many key concepts missing or misunderstood. Apparently there is a lack of consensus on how to do SOA well. That failure of SOA is caused by vendors’ products, issues with granularity or picking wrong places to split a system. These assessments of the problem illustrate the lack of understanding of the author and his colleagues. Yes, there have been SOA failures, but mostly they have arisen through a) a focus on integration technology not business, or b) lack of reference model, reference architecture and governance. As an aside, in mature SOA we don’t consider “places to split a system”; we define the scope of a service using well defined heuristics and techniques that vary by type of service. To claim therefore that microservices is the answer to problems with SOA is downright disingenuous. And given the amount of hype I see about the topic generated by supposedly responsible organizations such as Thoughtworks and Gartner, that’s downright irresponsible. Disappointing. 

Public Domain information on Mature SOA architecture and delivery practices

——————————————————————————————

Microservices Unplugged

by
Given my (well-known and enduring) interest in all aspects of services, I have followed Martin Fowler’s writing on microservices. But I will admit I always found the original paper more confusing than insightful. And in my client work I have resisted the temptation to use a microservices pattern, for precisely the reason that it would more than likely confuse. So I was interested to see the book Building Microservices by Sam Newman published last month, particularly as Newman is part of the Thoughtworks stable, which presumably means it is authoritative.  

Right off the bat, Newman advises that we should “think of microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile Software development”. These analogies are very interesting because my expectation was that microservices is a pattern. So I might infer that microservices is a set of process techniques as opposed to an architectural approach. Yet in the book, Newman clearly includes some elements of concept model and architecture as well as process and organization.

Probably the biggest weakness of Newman’s book is the absence of a coherent reference model. He discusses a series of heuristics such as:

                – Microservices are small, autonomous services that work together.

                – With high cohesion.

                – Gather those things that change for the same reason, and separate those things that change for different reasons.

                – Using business boundaries.

                – How small is small? Could be written in 2 weeks; small enough and no smaller; can be managed by a small team

                – Separate entity. All communications between services are network calls. Decoupled. Minimum dependency.

                – We need to think about what our services expose, and what they should allow to be hidden. If there is too much sharing our consuming services become coupled to internal representations.

And these are mostly useful principles, but are most unlikely to guide a consistent approach. Given Martin Fowler’s involvement, I would have expected at least some good patterns. But mature SOA needs a defined concept model, like CBDI-SAE, SOA-RM etc.

This lack of clarity is fundamental. Many organizations treat operations as services, and they typically end up with thousands of services. They will be confused by the very term microservice because they already have what they perceive as small services. Perhaps the term microservice has been chosen because of the ubiquitous use of the ITIL service, which undoubtedly means monolith. Most mature SOA organizations define services and operations as a primary technique to establish cohesion guided by reference models such as SOA-RM and CBDI-SAE. Just as important is the clarity and precision around specifications or contracts and what is exposed to consumers (APIs) and providers. Yet the book contains nothing on the subject of rich service specification or contract as the primary means of achieving implementation independence and business alignment. Organizations adopting microservices will need a defined reference model. Without that there will be architecture governance by personal opinion. I wonder how Thoughtworks advise their clients in this area? 

The book contains some quite general advice on business capability based decomposition – which is a tried and tested method of defining services. However there is little or no advice on what a well-formed business capability is, it’s characteristics and governance considerations. In my experience this is an area for considerable confusion; the business capability concept is so well known, but little understood, it’s an accident waiting to happen. And as for the relationship between capability and service, there’s no model provided, and more importantly, the granularity of a business capability service is likely to be non-trivial.

Similarly there’s no guidance on types of service. Do all services contain a mix of channel, process, business and data behaviors? Which you might expect given the explicit advice to gather those things that change for the same reason, and separate those things that change for different reasons.

The one area that might be helpful is the concept that microservices are highly autonomous, and a capability cluster of services would be a unit of deployment. But sadly for Newman, this is an idea that I and my colleagues worked on and popularized nearly 20 years ago. We called it Component Based Development, and the concept was closely allied to Rich Service Specifications which enforced the component boundaries, a concept that seems to have escaped him.

Once upon a time I had expected there to be a microservice pattern. But having read the book, all I see is a set of established ideas being rehashed in a very superficial manner, under a new name; with many key concepts missing or misunderstood. Apparently there is a lack of consensus on how to do SOA well. That failure of SOA is caused by vendors’ products, issues with granularity or picking wrong places to split a system. These assessments of the problem illustrate the lack of understanding of the author and his colleagues. Yes, there have been SOA failures, but mostly they have arisen through a) a focus on integration technology not business, or b) lack of reference model, reference architecture and governance. As an aside, in mature SOA we don’t consider “places to split a system”; we define the scope of a service using well defined heuristics and techniques that vary by type of service. To claim therefore that microservices is the answer to problems with SOA is downright disingenuous. And given the amount of hype I see about the topic generated by supposedly responsible organizations such as Thoughtworks and Gartner, that’s downright irresponsible. Disappointing. 

Public Domain information on Mature SOA architecture and delivery practices

——————————————————————————————

The Age of The Micro-UI

by

In this article from the Wall Street Journal, author Christopher Mims quotes mobile analytics company Flurry’s data that 86% of our time on mobile devices are spent in apps, and just 14% is spent on the web. While Christopher’s article laments that this is the “death of the web”, I’d like to put a different […]

The Open Group Boston 2014 – Day Two Highlights

by

By Loren K. Bayes, Director, Global Marketing Communications Enabling Boundaryless Information Flow™  continued in Boston on Tuesday, July 22.  Allen Brown, CEO and President of The Open Group welcomed attendees with an overview of the company’s second quarter results. The Open … Continue reading →