UML vs Masala diagrams?
I've come across this wonderful article touching on the subject of replacing engineering technical diagrams with fluffy ones. Or, as the author calls them, masala diagrams.
Why masala? Because they are informal; they cover multiple dimensions at once, they may be both structural and behavioural, logical and physical. They are often a mishmash of the 4+1 architectural model’s views.My customers and peers not only keep asking for more masala diagrams, but they also insist that I make them even more masala (that I merge more architectural dimensions in them!)
While sometimes these diagrams help to articulate 10,000 ft views to high-ranking stakeholders, I resist using just these diagrams and agile epic stories to convey solution details because it leads to unpredictable results most of the times. And as producing detailed UML diagrams for every aspect of the solution may be an overkill, some low level technically accurate details is required most of the times. This is especially true for sequence and system interaction diagrams, where it is clear which system is initiating connections, which protocol is used, whether it is a real time or a batch call.
As always, delivering a fit for purpose outcome is the key.
Fairytales of code reuse
I've been through numerous discussions about reuse during my career. It always starts with "Wouldn't it be nice if we written this wonderful code once and then everybody in the organisation will use it until the kingdom come?" .
We will create this service layer team that will write enterprise level services and other teams will consume them.
That is great in theory, but in the context of a large organisation these dreams crash against the wall of reality.
Let's assume you have a version of a service that retrieves customer policy/account data from a data store and you want everyone to retrieve it using it. You, obviously, want to pack as much of a business logic into this service, because…reuse, right?
You spend some time collecting all the use cases about all the information you could possibly need to be returned and then write this wonderful service, hacking away all permutations and edge cases that cater for all potential consumers.
You even persuade 10 various consumers to use it. And then the fun begins. Consumer #3 wants a slight modification to the service output due to new regulatory requirements. What does it mean?
More often that not, it means that in addition to the Consumer #3, all other consumers need to perform impact assessment on how does the proposed change impact them and, even if it is not impacting them, they will have to participate in regression testing activity which needs to coincide with the release for Consumer #3.
- What does it do for their respective team schedules?
- Do they all have developers or BAs available to perform the tasks?
- What is the process and cost of creating new environments?
- What if one out of the consumers' tests fail?
- Etc.
Host projects tend to have limited budgets and therefore they have no desire in paying for anything that isn't directly related to the project's outcome, hence, they will insist to have a special case service built just for them.
So a couple of years down the track you are very likely to find yourself with multiple versions of the very same service, built for various consumers at different times, each with minor variations.
Thus, despite the noble goals of building one super-service that does it all for everyone, the organisation will end up with a collection of custom-built, consumer specific services that are centrally managed by a shared team that has very little knowledge about why exactly each of the versions is built the way it was.
What is the solution?
Often, it is better for services to return full raw responses and let consumers deal with the data interpretation in a way they see fit - chances are you will write less code, the code will be much cleaner and the business logic will be owned by the team that actually uses it.
Or, as Martin Fowler put it, use >> reuse.
Years of experience != skills
Typical recruitment approach of seeking years of experience as opposed to skills and references is often counterproductive and sometimes results in funny outcomes.
Abandon IT Security fortress mentality
An interesting article covers Aruba's opinions on secure fortress mentality:
"Aruba's recommendation is to do that by providing providing people who work from home with an office-grade wireless access point. It plugs into their existing modem/router and creates a separate Wi-Fi network for work use."
Well, while this will work, it is a hack that doesn't really fixes core issues of poor network security and creates additional pain for workers, especially the ones on the go, it creates inconvenience around context switching (e.g. Modern blend of personal and work tasks). I think there is no way around securing internal IT infrastructure properly based on Zero Trust Network. #zerotrustsecurity
