First there were SOA principles, then came anti-principles. While SOA architects and developers are still arguing what those really mean and how to apply them, in his new post Steve Jones presents a third concept - non-principles. According to Jones, while creating SOA (or any other software implementation for this matter) you typically have to deal with:
- The principles - what good looks like and is measured against
- The anti-principles - what bad looks like and is measured against
- The non-principles - what you really couldn't give a stuff about ...
As Jones explained in his post:
... [while] the non-principles... might sound like an odd concept... it’s one that has really paid dividends for me over the years. While Principles say what you should do and anti-principles say what you shouldn't, the non-principles... is something that you don't give a stuff about. You are explicitly declaring that it’s not of importance or consideration when you are making a decision.... While you can evaluate something against a principle to see if it is good or against a non-principle to see if it is bad the objective of the non-principles is to make clear things that shouldn't be evaluated against.
Translating this in a familiar terms - non-principles is something that is explicitly defined as a non-goal for a given implementation. The introduction of non-principles provides the ability to deliver on time and on budget by ignoring some of the quality requirements, which are not part of the stated goal of a given implementation. According to Jones:
... the non-principles are very context specific and are really about documenting the perceived wisdom that is wrong from the programme perspective. The non-principles are the things that will save you time by cutting short debates and removing pointless meetings... Non-principles clearly state what you will ignore, they don't say what is good or bad because you shouldn't measure against them...
To prove his point Jones gives several examples from the projects he participated in where the use of non-principles was instrumental for project’s success.
Although it is hard to argue about the importance of principles and anti-principles in an SOA implementation, the introduction of non-principles seems slightly artificial. The issue here is that in reality there are no non-principles, but rather implementation goals and consequent architectural tradeoffs. If we take Jones’ first example - "performance not an issue", it does not mean that performance does not matter. What it means is that performance is not the most important architectural goal of the implementation, but there is typically still a performance constraint for a given implementation which has to be met (although the actual number can be relatively high). His next example - "data quality is not important" - again, it does not mean that a new system can contain inaccurate data. It really means that data quality improvements were not stated as direct goal of the project.
It is extremely important to understand what the overall goals of an implementation are and to make appropriate tradeoffs, but it does not seem to qualify as a completely new category - non-principles. Rather, it seems that we need to realize what is really important for a given program and focus on that.
/filters:no_upscale()/sponsorship/topic/bfe5192b-a45b-4f11-a690-3612a3462921/TeleportConnectLogoRSB-1665047515149.png)
/articles/framework-architectural-decisions/en/smallimage/logo-1679060242842.jpg){kind=logo}
/articles/istio-ambient-mesh/en/smallimage/logo-1678364642232.jpg){kind=logo}
/articles/effective-architecture-conversations/en/smallimage/have-effective-conversations-with-business-stakeholders-about-software-architecture-small-1677231728391.jpg)
/articles/creating-decentralized-apps/en/smallimage/LOGO-1676916574942.jpg){kind=logo}
/presentations/data-streams-architecture/en/smallimage/Kai_Waehner-s-1675025271514.jpg)
/articles/architecture-skeptics-guide/en/smallimage/a-skeptics-guide-to-software-architecture-decisions-small-1672223516348.jpg)
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/articles/architecture-architecting-role/en/smallimage/logo-1670404086277.jpg){kind=logo}
/articles/technical-debt-tells-you/en/smallimage/logo-1669820164127.jpg){kind=logo}
/articles/remote-working-team-topologies/en/smallimage/logo-1669733754633.jpg){kind=logo}
/articles/ebpf-service-mesh/en/smallimage/ebpf-service-mesh-small-logo-1665571213645.jpg){kind=logo}
/articles/high-fidelity-data-streams/en/smallimage/building-and-operating-high-fidelity-data-streams-small-logo-1664284454024.jpg){kind=logo}
/articles/cognitive-load-platform-engineering/en/smallimage/logo-1668609260559.jpg){kind=logo}
/presentations/infrastructure-control-plane/en/smallimage/Daniel Mangum-s-1665739290818.jpg)
/presentations/stripe-dev-env-infrastructure/en/smallimage/Soam Vasani-s-1664525808854.jpg)
/articles/secure-software-development-gitops/en/smallimage/accelerating-secure-software-delivery-lifecycle-with-GitOps-small-1679658720410.jpg)
/presentations/refactoring-rust/en/smallimage/qcon-plus-s-1679694299933.jpeg)
/presentations/aws-apache-airflow/en/smallimage/qcon-plus-s-1679694143127.jpeg)
/articles/billions-messages-minute/en/smallimage/LOGO-1679471830613.jpg){kind=logo}
Community comments
Doing away with Central principles/practices in SOA
by aditya yadav,
Be sure the business understands
by James Watson,
I'm somehow pro-experimentation
by aditya yadav,
Re: I'm somehow pro-experimentation
by aditya yadav,
Doing away with Central principles/practices in SOA
by aditya yadav,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have been an architect for more than a decade but I'm also an Agilist and a part of my work revolves around Organizational Architecture/Restructuring/Culture etc.
80% os SOA projects fail and everyone says it takes 10-15 years to get a SOA transition right. I don't agree, all it takes is 5-6 months to get on the right track. As a non-principle I would like to suggest "Central Governance", "Central Registries", "Central Service Lifecycle Management" as non-principles. SOA projects don't fail because of poor Governance but rather because of Governance itself. Most central organizational structures/teams/groups fail very soon as they become single points of failures and are easily overwhelmed. Especially in the case of SOA where the coordination effort is enterprise wide. The most scalable software systems and org. structures are ones that are without the concept of one global truth, or one person/team (oracle) who knows or controls all.
We face a lot of resistance when we talk about these ideas to people other than our existing customers primarily because Central Governance etc. means big business for most vendors. And Companies find it non-intuitive/contrarian as they have see Corporate Governance flow down to IT Governance and then take the shape of SOA Governance and they know no other way of doing things.
You have to see it to believe it. But since I can't invite everyone to be a part of the action at our clients companies. The next best thing I can offer is for the readers to go through my book "Essays on SOA & EAI - A Pocket Guide" to understand where we are coming from and how we have succeeded in every SOA engagement we have touched in the last 4-5 years. If you agree with what you read you should also look at the pocket guides on leadership and innovation which address other organizational issues.
Cheers
Aditya Yadav
adityayadav Dot com
Essays on SOA & EAI - A Pocket Guide
Essays on Leadership - A Pocket Guide
Essays on Innovation - A Pocket Guide
Be sure the business understands
by James Watson,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm not sure I agree with #1 and #3 is a bit dangerous. The issue I've seen with assuming that you can implement a service against future business rules is #1 these rules are unproven. They may or may not be right. #2 Business owners often don't understand the implications of these kinds of decision and they are often reversed.
If the author was consulting when that solution was implemented, I would strongly encourage him to follow up with the business and see if who well that went. I've seen many such decisions result in unused and unusable services. While in the consultants mind the project was successful, if the service(s) doesn't provide any value, it's not a success for the company that paid for it.
This is part of a larger problem I see in IT. The value of the software being produced is often ignored. Often software is developed to meet requirements that have nothing to do with what the company needs. While it's convenient to state that the business will conform to the new package, if you don't know that they actually will (or can) you are just being lazy. It's better to spend more to build something that works than get something that doesn't work on the cheap.
I'm somehow pro-experimentation
by aditya yadav,
Your message is awaiting moderation. Thank you for participating in the discussion.
I believe a lot of times the business doesn't know or understand what it needs now or in the future. And hence they would like to experiment with ideas, concepts and rules.
A SOA project that is not agile enough to support experimentation by the business somehow handicaps business progress and evolution of strategy. I would like to step back and draw an analogy from google. Engineers @ Google are free to setup an experiment (Google facilitates time and resources) and hence the company produces pretty excellent products and strategies.
Even if the business doesn't understand what it needs, while a healthy debate is helpful the IT should be agile enough to deliver an experiment quickly, refactor it back to original if it doesn't work and be good. Today I don't want to hear the word IT too often but rather Business Technology.
My 2 cents.
Re: I'm somehow pro-experimentation
by aditya yadav,
Your message is awaiting moderation. Thank you for participating in the discussion.
Apologies
The point I was trying to make is that ...
"The ability to Experiment" is an essential principle of a SOA Transition.
Aditya Yadav
Aditya Yadav & Associates
Amazon Cloud Computing With C#/.Net
Amazon Cloud Computing With Java
Understanding Programming Languages
Deploying HTML5
Essays on SOA AND EAI - A Pocket Guide