Forget the Fads — It’s Time to Think Architecturally – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Forget the Fads — It’s Time to Think Architecturally – InApps in today’s post !
Read more about Forget the Fads — It’s Time to Think Architecturally – InApps at Wikipedia
You can find content about Forget the Fads — It’s Time to Think Architecturally – InApps from the Wikipedia website
Jeff Kelly is a director of product marketing at Pivotal Software. He spends his time learning and writing about how leading enterprises are tapping the cloud, data and modern application development to transform how the world builds software. Prior to joining Pivotal, Jeff was an industry analyst at Wikibon and a reporter at TechTarget.
In sports, having the right mindset coupled with practice is often as important as raw, physical skill. Something similar is true when it comes to software engineering, according to Nathaniel Schutta. Unfortunately, some software architects don’t often spend enough time on mental preparation or practice. The results are predictably poor.
“The average architect may only work on a small handful of applications. How are you supposed to become a master without the needed practice?,” writes Schutta in the introduction of his new eBook, “Thinking Architecturally,” published by O’Reilly Media. “Professional athletes spend far more time practicing their sport than they do playing in games that ‘count.’ Professional musicians and actors spend countless hours rehearsing before performing in front of a live audience. But beyond a perfunctory class, most architects learn on the job, meaning they make their mistakes on live projects. Is it any wonder so many software projects fail to deliver the expected value?”
In “Thinking Architecturally,” Schutta provides a framework for those in software architect roles, whether they are called software architects, enterprise architects or senior or junior developers. He encourages these folks to take a leadership role, and to be more assertive. This involves being a guide for product teams through their technology journey. Put in the hard work for what isn’t a necessary part of your job for a client or real end users away from live projects, while continuing to learn and grow as technology professionals.
Schutta, a software architect at Pivotal, tackles such topics as keeping up with new technologies without getting overwhelmed, evaluating trade-offs and introducing new technology and approaches while limiting disruption.
He ends each of the book’s six chapters with a “Katas” section. Katas is a system of individual training exercises for practitioners of karate and other martial arts. Applied to software architecture, an “architectural Katas session,” writes Schutta, gives “participants an opportunity to work through pseudo real-world problems and its architectural issues.”
In other words, and as former NBA star Allen Iverson would say, we’re talking about practice.
The Times They Are A-Changin’
One of the biggest challenges software architects — and frankly everyone else in IT — face is keeping up with changing technology. Just when one technology seems to have solidified itself as the next big thing, something else inevitably comes along to claim the title, albeit temporarily. This aspect of the industry can be overwhelming for even the most seasoned software architect.
In the book’s opening chapter, Schutta recommends software architects get out of the prediction game. There’s no way to tell what the hot technology of tomorrow will be. And don’t constantly jump from new, emerging framework to new, emerging framework. It will only hinder your growth as an architect, not enhance it.
“If we are constantly experimenting with the new, we never develop any expertise in the now. Changing frameworks every few months might keep us at the forefront of buzzword bingo, but it is hard to be good at something you’ve just picked up,” writes Schutta. “And as tempting as it is to just throw away the old and rebuild on the ashes of the past, it is hard to deliver any business value if we are in a constant state of flux.”
Just as important, there is value in legacy skills. You can make a very good living, writes Schutta, when you’re one of a dwindling few architects with an expertise in a legacy technology.
At the end of the chapter, Schutta provides a number of mental exercises for architects to practice to better deal with fast-moving technology trends. Here is one example:
“Think back to a technology that, despite the fanfare, didn’t take over the world. Why didn’t it? What was lacking? Is there anything that could have changed the outcome?”
However, change is inevitable. There will come a time when you need to make a decision between two competing technologies. Perhaps one is a shiny new object, while the other is an older but proven technology. How do you decide? In chapter four, Schutta offers 16 criteria to use when making a technology selection, starting with the quality and clarity of the documentation.
“The era of ‘The Code is the Documentation’ is over,” writes Schutta. “Is the documentation clear and concise? Is it up to date? Is there enough to get you started as well as enough to keep you going? What you need from the documentation will change dramatically from week two to year two.”
Other criteria include the quality of the code base, its testability, corporate fit and licensing model.
Then there’s the politics of technology selection. Different stakeholders in your organization will undoubtedly have their own opinions about your technology choices. Be prepared, writes Schutta, to navigate the political waters when selecting technologies. To increase your chances of success, it’s always a good bet to align the technology to executive-level goals.
Writes Schutta: “For example, years ago a new CIO made it clear that release weekends included far too much drama and he wanted to see improvement. A few of us used that as an opportunity to reintroduce a set of code quality initiatives we’d been advocating with limited success. By connecting that drive back to the CIO’s goal of smoother releases, we made significant progress.”
As with every chapter, Schutta winds up chapter four with Architectural Katas exercises:
“Compare and contrast two similar technologies. What criteria did you choose? Why?
— Which one came out on top? Why?”
“Consider a technology you would like to introduce to your organization: What political roadblocks exist? How could you manage the politics of that technology?”
Get Your Copy of ‘Thinking Architecturally’
These are a just a few nuggets of wisdom from “Thinking Architecturally.” The entire ebook is worth a read by all enterprise software architects. Schutta’s writing style is accessible while incredibly informative. Read it more than once. Keep it on your desk. And don’t forget to practice. Thinking Architecturally is available now as a free download.
Pivotal is a sponsor of InApps.
Feature image via Pixabay.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.