Contemplating a move to the other side of the country as we look to living by the coast, has given us an opportunity to catch up with what is happening across the home building landscape. In so doing, it’s so easy to gravitate to what’s trending and to ignore the practicality side of things. There is always the question too as to whether this or that trend has legs sufficient enough to overcome future reactions about how dated such a trend has become.
Touring the many model homes
that builders provide is always an exercise in maximizing temptations. This
home can be built at this price point but if you would like it to look more
like the model, then the upgrades will run you 20 to 25 percent more than the
described base price. Models have their purpose but then again, they tend to
not only tempt potential buyers but oftentimes overachieve. Do we really need
floor to ceiling sheets of marble as wall coverings? What about that massive
chandelier above the entrance?
The references to models and
architectures, let alone the choices of frameworks – cinder blocks, aluminum or
timber; your choice – leaves the average house builders scratching their heads.
Having built two homes already and now contemplating a third, we are at least
approaching this latest decision with considerable caution. Educated fully?
Perhaps not! But enough to say that we know what differentiates a good build from a bad build and we know not to add massive changes at build time. Indeed the build trends are witness to shortening timelines as more and more decisions are predetermined “by the team.” So much today is delivered to a building site already prebuilt thanks to the power of modern CAD/CAM applications.
Having attracted your attention, imagine then how I reacted when, scrolling through the posts to LinkedIn, I came across this:
Is
software architecture still relevant these days?
Does it mean that the architecture has become irrelevant as well?
Several rules have changed mainly after the agile methodology,
including the architect as a deprecated role.
Having
a unique person to drive the whole organization's
architecture breaks the agile methodology and the new
methodology against the top-down model.
Empowering the team if the decision lies with one person
does not make sense.
Software
architecture is in any decision, with or without care.
The high point is that when you don't care or believe
that the architecture will magically appear, the consequence is that the
organization will be a hostage.
Otavio
Santana
Software Engineer | Software Architect | Speaker | Writer
June 15, 2022
I couldn’t let an opportunity to comment on this short post go by without looking at it again, based on what has been introduced of late at numerous HPE NonStop events. Ignoring how many occupants we have along the corridors of the C-Suites – the CIO, the CTO, the CRO and yes, the Chief Technologist and even the Chief Architect (and I am sure I missed naming many more) – when it comes to designing, producing and then deploying a new application or solution, can we ask whether there is a need any longer for architectures, models and frameworks? Surely, the answer is that in pursuit of the customer experience (CX), timeliness is next to godliness and cannot be forsaken in the pursuit of the purity of design.
Or can it? Looking back at the good times in IT that happened in the 1970s – 1980s the change was indeed constant. There were architectures for networking, writing code, developing whole applications and much more. Remember SNA, HIPO (Hierarchical Input Processing Output) charts and yes, SAA. Thanks needs to go to IBM for challenging us all to think more intensely about how to maximize our skills while reducing the time to develop and then the cost to support. But seriously? Have you even tried to use HIPO or whiteboard an SAA possibility?
Put this down to just how long it took to program an application. Back in the day it wasn’t uncommon to plan the creation of a new application and to expect a five years, perhaps longer, development and testing cycle. During the design phase, it wasn’t uncommon either to select an architecture or at the very least an overall style or approach to guide development. Programs were to be written in Assembler, COBOL or PL/1 (if you shop was IBM centric). Communications was based on BTAM and later, VTAM and files could be a mix of BDAM, ISAM and VSAM.
What became important was the ongoing support considerations along with the future access to qualified staff. But the presence of a chief architect? Didn’t happen for many years, indeed decades. The design remained important and a good design meant the return on the developers of an application would allow the application to continue providing results for much longer than anticipated. Thinking through the how, and the what that went into a design remains important to this day.
With the speed of development and deployment of a new application (or app) demanded by business today calls for considerably more off-the-shelf components and less custom designed components. The presentation of a development cycle for something new that calls for a five plus year timeline just won’t cut it any more. For a time, we have seen the presence of software architects and their influence has been considerable and yet, as the blogger noted, “organization's architecture breaks the agile methodology.”
Furthermore, according to this blogger, if "you don't care of believe that the architecture will magically appear, the consequence is that the organization will be a hostage." Seriously? Strong language, indeed. My actual programming days are long behind me – wrote my last code, June 1979. The programming languages, utilities, APIs and services are vastly different these days but the value of a good design is still very hard to ignore even as I continue to remain on the perimeter of development projects to this very day.
Where this experience of
mine has taken me to is that small, knowledgeable teams deliver the best
results where the presence or absence of software architects matters little.
Such small teams are capable of thinking through the potential pitfalls in a
manner that greatly reduces the potential for glitches that so often lead to
media headlines. It took a very small team led by one individual to develop an
alternate operating system for the IBM mainframe back in the 1970s. And it was
superior to the IBM offering.
More recently, for the
NonStop community, it was a very small team that brought ICE to the market and
that led over time to the demise of the Tandem’s offering. It also led to the
development of uLinga where you will find the same small team hard at work. More
recently, much the same can be said about the origin of DRNet (and GoldenGate
that followed) and there are many more examples that can be referenced. The
point being, these excellent products and for me, DRNet remains the gold
standard for D/R, weren’t the result of massive investments in procedures,
architects, frameworks and more, but rather relied on the team recognizing and
exploiting a good design, be that from a whiteboard or bar napkin. Let’s
approach with caution as yes, we need to be cautious, carefully threading the
needle between the ambitions of some and the necessity of others.
So, with this being said,
here is my dilemma. When racecar drivers first start out, they are instructed
not to develop tunnel vision and to stop peering at the taillights of the car
ahead as this only leads to them following that car off track should that
happen. Lift your eyes, look far ahead and develop a strong sense of
situational awareness. I see parallels when it comes to creating applications
as it is abhorrent to information technologists to simply maintain the status
quo. Fixated on even the most beneficial architecture discounts the possibility
of embracing something new and perhaps more relevant to your own situation.
My dilemma is also fueled by
my own appreciation for sound architecture with a lower-case a, then it is for
Architects with a capital A. Likewise, frameworks today offer little more than
a view of the past and for the most part have become support for what we all
appreciate as “marketecture.” As for models, templates, etc. (but not including
access to libraries and stubs), they tend to lock you in to your fellow novice
racecar drivers. Curves ahead; be aware, eyes up! It all comes down to the
designs, the gifted teams communicating well and a clearly defined customer
objective. Simple, isn’t it?
Well not so fast; entrenched
bureaucracy is hard to dislodge. The desire to charm with PowerPoint slides and
the need to project an all-knowing image still persists. Thankfully, for the
NonStop community today, we have seen almost everything in our time working
with NonStop, so much so that very little of what is written here comes as
news. On the other hand, as we head into the major events season – HPE Discover
followed by the NonStop TBC 2024 – be prepared to hear more about models and
frameworks from Architects and a question is; do we really need all this
superfluous overhead?
And in closing and
remembering from my childhood those famous words uttered during morning roll
call on Hill Street Blues, “Let’s be careful out there!”
Comments