Tuning your software architecture or moving from a Cacophony to a Symphony!

A question that has bothered for years. Is the difference between a symphony and a cacophony the point of reference of the listener?

Or is the difference the quality of the sound?

Does the instrument being played impact the quality, point of reference or modify the impact of that sound?

My symphony could simply be the sounds of Cicada’s. Many find that to be a cacophony as they leisurely stroll at the end of the day. The point of reference not only the physical location of the person, but also in the end the ear of the person.

Software architects deal with that phenomena all the time. Understanding the point of reference not only for the person viewing what has been built but also the other considerations (viewpoints) they may offer modifying the original view.

The thing that always intrigued me is the intersection of views. Not the many viewpoints because frankly those are created by simply viewing an architecture. Rather the point at which a series of views of a solution intersect. The views come from various points of reference. A business person worries about the completion of a task or series of tasks resulting in the creation of value. A technical person may look at the solution as old or new existing or boring. An administrator may worry about how “do I” manage the overall solution. Finally a security person worries not only about what is being built, but what data is being input into the system and what data is being generated in the end how “do I” secure the entire solution.

It’s simply a personal view. Changed and modified not only by your own personality and traits but also the function and role you have in relation to the solution. My natural symphony “Cicada” sounds like a cacophony “gross bugs” to my neighbor and so on.

The impact of a solution depends upon your point of reference. The view that comes to you first is wholly based on where you start. The software architects job is to enter the room and in the end determine the many points of reference in the room in building a solution.

Going back to my post of yesterday on bandwidth and security impacting IoT let’s play that forward into the various view’s brought into the room. In software architecture training we tell you that you create the views. But some views of what you’ve created are actually brought into the room.

· Business on bandwidth: That is an IT problem.

· Business on security: high impact.

I realize those are very generic but in the end you understand the impact of what people think as they walk into the meeting. They have preset notions of what is possible and why it is possible. Based on those preset notions they then interact with the solution you are presenting differently.

What then does the software architect do? How do you get around the preconceived notions people have about technology. Those notions can be pretty negative (costs too much, doesn’t add value, ROI is far to long, change is bad and so on). To some people that beautiful architecture isn’t a symphony its just a bunch of loud cicada’s!

To finish getting the bugs out of your solution isn’t just part of development. It is in the end also a part of selling the solution to others in the design phase. If your solution appears to be cicada’s you may struggle to get other’s to buy in.

.doc

Scott Andersen

IASA Fellow.