#2 Default to Transparency · Architecture is...? · CD by the book
Default to Transparency
I don’t know if it is deeply rooted in Japanese culture or if this is just one of those anti pattern you encounter in most big organizations. Either way, the MO in at my company seems to be: restrict read access to as few people as possible. If you want to Increase visibility you require explicit justification.
Sounds like a good idea, doesn’t it? Why should Greg (from the other department) read my design documents? Why should Jenny or our teams’ source code? As it turns out there are very good reason for Greg and Jenny access your stuff!
Good Reasons for Transparency
Direct reasons for other teams to get read access to your documents include reviews, compliance and auditing. In order to review your software design; In order to ensure that your system is compliant with GDPR or PCI DSS; In order to conduct a white-box security audit of your source code; in all of these cases other teams in the organization (or external experts) need to read your stuff.
A semi-direct reasons for company internal transparency of communications and documents accessible is effective & efficient communication. That decision you make in a secret slack conversation with 3 others - without a readable record of it… well it pretty much did not happen. Especially in times of remote work. Previously I wrote about meetings:
A meeting without follow up communications or documents might as well not have happened at all as far as outcomes are concerned.
Secret slack channels are the new meetings.
Bad Reasons for Secrecy
Then there are indirect reasons to make your work to be transparent to the rest of the company. These are really just the inverse of bad reasons to keep things secret - the negative side effects of secrecy. Problems you can avoid by transparency.
Source Code: Keeping credentials in source code repositories is undeniably a horrible practice …but if our repo is only readble by 4 people it seems acceptable. That feeling is wrong, storing credentials in source code is never acceptable. By restricting read access to source code you facilitate a false sense of security. In other words: your system is less secure, you add risk.
Audit Reports: Security issues reported by an audit can be embarrassing. However if you keep them to restricted to managers and leaders only then the rest of the team don’t know what to improve. Or how to avoid that security issue in the future.
Moreover accepting the risk of a security vulnerability in secret seems less irresponsible. “Well, attackers don’t know that we run Java 6 / PHP 5 / openssl 1.0.1 / etc. So the risk is not that high”. By brushing security issues under the rug you add risk.
Wiki Pages: I get it, you own that wiki space, it’s all yours, you’ve got the power. But by hiding those pages of product requirements, software designs and meeting notes from other teams you impede collaboration. You put yourself between information and knowledge workers, you impede progress. Impede as in: the opposite of “enable”. Impede as in: the opposite of empower. Impede as in: the opposite of servant leadership. In effect you increase cost (best case) or reduce productivity (worst case).
Good Reasons for Secrecy
Ok let’s be fair, let’s hear the other side of the argument. I see 3 valid reasons for secrecy:
Credentials: Passwords to systems, database username and passwords, access tokens, etc. - Anything that a human or a system uses to authenticate or authorize access.
Strategic assets: An algorithm that is a competitive advantage, a strategic plan that competitors must not know about, a plan to acquire another company.
Personal Information: HR information, exchanges between manager and reports, career development plans, etc.
All of these should be kept secret - but properly secrect. Put credentials into a secrets management solution like HashiCorp Vault, put strategic plans into a secrect page tree in your wiki, keep HR information in a dedicated system like WorkDay. Everything else should default to transparency, to company wide read access. Let’s call it company-public.
Reflecting on the these reasons for and against transparency I conclude that:
Everything should be company-public by default.
The only exceptions are credentials, strategic assets and personal information.
Reducing visibility of any other piece of information requires justification.
Is that delusional? Or do you agree with me?
How does your organization handle secrecy / transparency?
Architecture is…
I’m starting a software architecture team in my organization (see last week). This week I finished recruiting a team of ~10 team members with differet backgrounds, roles and experiences. Only one of them has “architect” in their title - which I like. I want the team to be hands on, practical, pragmatic. We don’t need ivory tower, theoretical architects in the org. But this also poses a problm: Everybody has a different understanding of what “architecture” is.
I can’t really blame them, there is so many definitions out there. Then there are the cargo cults of micro services architecture, monolithic architecture, service oriented architecture etc. Then there is the fact that we programmers borrowed a term from construction - a metaphor falls apart really quickly.
It is a daunting, not easy to grasp in a single sentence.
All the oneliners are entertaining, they ring true, but none of them are really instructional. Architecture is…
…the important stuff, whatever that is (Making Architecture Matter)
…the shared understanding of the system by expert developers (Who Needs an Architect?)
…the stuff that is hard to change
…structure, characteristics, principles and decisions. (Fundamentals of Software Architecture)
…structure, non-functional characteristics, dependencies, interfaces and construction techniques.
On the other end of the spectrum are the definitions by ISO / IEEE - unfortunately those are mostly useless as a primer.
At the end of the day all the definitions are merely approximations, individual facets of the real thing. They are projections of a higher dimensional object onto a lower dimensional space - like a shadow. A single one of them is not enough to re-construct the original.
In order to align my architecture team I will draw from several sources, starting with “Making Architecture Matter” & “Who Needs an Architect?”, material drawn from “Fundamentals of Software Architecture” and the “Thinking Like an Architect” blog series #1, #2, #3, #4.
Continuous Delivery - by the book
Last week I discussed continuous integration (CI) and continuous delivery (CD). I focused on the distinction between the two and said
CI deals with development concerns.
CD deals with deployment concerns.
The distinction is useful to decide if your pipeline is CI or CD and where to put automated task X (Is it a development concern? Is it a deployment concern?) . However that is incomplete, because I left development and deployment concerns undefined and their relation unclear.
As result I got the examples for CD completely wrong.
CD Spring web app = put the jar into a container image, deploy that to k8s
CD Native mobile app = upload that app binary to AppCenter or AppStore/GooglePlay
Those examples are veeeery incomplete. How so? Well those binaries are not ready to release! I failed to mention accetance, architectural fitness and manual testing 😬
Citing from the “Continuous Delivery” book:
The deployment pipeline:
Commit Stage: compile, unit test, analysis, build installers
Automated Acceptance Testing
Automated Capacity Testing
Manual Testing: showcases, exploratory testing
Release
A more complete picture. And that is what we do in my teams… kind of.
The reason for my previous omission is that we don’t integrate those activities into a singule pipeline yet. At the moment we have several pipelines, siloed by activities (dev, QA, devops). I am working on changing that, but with separate development, QA and devops teams I am struggling with Conway’s Law. No single team takes owns delivery, therefore no single team owns the CD pipeline.
How do you implement CD in your team? I’d appreciate your advice.
That’s it for this week.
Get the next issue right into your mailbox, fresh of the presses, still warm and icky.
Press the button.
Do it.