IASA

The software architect is known by many names; application architect, technical architect, solutions architect, are just a few of their aliases. The software architect is generally considered the key technical strategist or resource for a single system, solution or project (they may to have this role on 1-N projects or systems at a time). The software architect will often spend a significant portion of their time considering actual code level issues and designs. Interestingly, this is also a debate in our community. Many industry pundits argue back and forth as to how much time an architect should spend writing, reading or designing code and what tools they should use (see the Great Architect Debate). What we do know is that the qualified software architect is the core design and technical resource for their projects or systems.

In many cases the software architect enjoys a special place in the technical community. They are characterized as solution oriented, hands on and providing real value. They are often perceived as being able to speak the language of "the business". If coming to the role from a development background they are often extremely well-regarded by the development teams. However, in some cases there is significant frustration with the role. Some software architects design solutions which are flexible but do not meet the needs of other constraints. Some do not consider the enterprise perspective and end up creating additional silos of functionality or investment. In many cases, the role is considered, "where developers go to die" or more specifically, the role given to a sr. developer when there is no higher "technical" position for them to fill.

by Nicole Tedesco
Tectura Aerospace
http://www.Tectura.com/Aerospace/

Michael is a consulting Software Architect and very unhappy.  The problem is his recurring rash which his doctor says is triggered by stress.

Michael’s wife is wonderful, his of his children are well-behaved and above average, and even his in-laws are a joy to have over for the holidays.  His home life is fine.  Michael’s rash-causing problems however come from his life at work.

After spending three months analyzing enterprise requirements to help his client survive an impending acquisition he confronted application designers, service designers and product managers to elicit constructive feedback on his first draft enterprise architecture.  “My biggest problem,” Michael admitted, “was developing my recommendation for the integration technology.  There were many trade-offs to consider.  For reasons I will be glad to expand on if you want, I strongly recommend we standardize upon Java Message Beans for message consumption across the entire service bus.”

“Well actually,” Alex began.  Michael knew that trouble was brewing whenever the pony tail-sporting, gadget geek hipster began any sentence with those words. “I’ve always liked using scripting languages for situations like that.  Message consumption is a small task and one we shouldn’t spend too much time on.  We should be concentrating our energy on pure intellectual property, not infrastructure issues like message consumption.  Scripts are much quicker to write than compiled code like Java.”

“Certainly,” said Michael, suddenly on the defense, “I agree with you to some extent.  However, controlled testing of scripts is always an issue—“

“Ruby comes with a debugger!” The Game had begun.

“Are you going to debug by hand a hundred Ruby scripts for each regression scenario or would you rather have the automation of JUnit tests—“

“I can easily write a test harness in Ruby!”

“You can,” Michael emphasized, “but what happens when you win the lottery, retire to beach front property in the Cayman Islands, and no one else is left here who understands Ruby to the extent that you do?  You’re not seeing the Big Picture here—”

“Let’s concentrate on realities, shall we?  Do you really think I am going to win the lottery tomorrow?” Alex had a sly grin subtly etched into this face, and the laugh lines to either side of his lips were starting to deepen.  “Ah, hah!” he seemed to want to shout.  Michael knew this look and understood that Alex took joy in any occasion to indulge in righteous indignation, whether he was indeed righteous or not.  Even above coffee, this was Alex’s drug of choice.

Michael also knew that Alex had never used the Ruby language, had never developed message consumers, and had in fact never used an “enterprise service bus” in his life.  It didn’t matter though since Alex had his groupies; the heads of those that wanted to believe everything that Alex had ever said were wide awake in that meeting, while those that were just tired of dealing with Alex under all circumstances abstained from positing any opinion at all.

Later Michael was confronted by the Chief Information Officer who gave Michael a stern lecture. “I hear my team doesn’t approve of your recommendations.”

“That’s not true.”  Michael was on the defensive, yet again.  “There was a single problem with one person with only one of my recommendations…“

“I heard this from multiple people, Mike.”

Michael hated the diminutive, being a source of childhood pain which he wore in plain view whenever someone used it by accident.  The CIO had worked long enough with Michael to know this.  “Only one person gave an objection which has no foundation—“

“These people have been with the company for years, and they have made us successful so far.”

“But you are the verge of a major change.  Many of the old rules no longer apply and I don’t think you can survive with the old standards of behavior.”

“So, I am to trust you over all of them?  I don’t think this is going to work out.”  Michael’s tenure with that client ended at that moment.  The next day Alex was promoted to Enterprise Architect and was charged with “leading the company into a new era.”

Three years later that company filed bankruptcy due to excessively high operational costs.  Most of the IT staff was laid off, while Alex was kept on in order to help implement a “leaner, meaner organization.”  That company never recovered its former glory though Alex’s resume looks great to this day.

            Marybeth recently quit her job as an Application Architect.  She had always considered herself a studious sort, well-read, skeptical of all she heard and preferring real proof to say-so and hearsay.  In all of Marybeth’s endeavors she has sought to do the right thing and always, always, always do Good.  “To paraphrase Samuel Johnson, ‘Ego is the last resort of a scoundrel!’” she liked to say.  The Good, as she saw it, was more important to her than what people said behind her back.

            One day Marybeth met with her company’s Enterprise Architect.  He was seemed like a good man, and was certainly attractive.  Suresh, of Indian decent, was raised in London, graduated from Harvard, accepted his first job in Tokyo, got his biggest professional break in Milan, and now towers saintly in high echelons of Marybeth’s company.  The always sharply-dressed, soft-spoken Suresh called Marybeth in for a review of the latest version of her critical application architecture.  “You do great work, really!  I love the way you have managed to maintain the quality of your legacy applications over the last two years, and I am awe of the way you handled the Contracts service.”

            “Thank you!” Marybeth was beaming, obviously, with pride and joy.  Who wouldn’t?

            “I mean that.  Be proud of yourself.”

            “I am.”  Suresh, the deference paid to him by others in the company, his worldliness and obvious intelligence made Marybeth blush even more than she would have normally in this situation.

            “I have to ask you though, what is the Finance Façade?”

Marybeth figured, surely Suresh must have a lot on his mind, and that he couldn’t possibly know the specifics of every application running in every subsidiary in every country connected to this company’s internal network.  “Oh, that?  It brokers Internet service requests for financial information originating from our mainframe farm.”

“It is a legacy system then?”

“Well, yeah.  We have had the mainframes here for decades!”

“I mean the Finance Façade.  How long has it been in service?”

Marybeth thought about it for a moment.  Rolling her eyes upward and to her left, she slowly leaked an unsure answer, “I think—um—I think, about five years now.”

“When was the last code change to that Façade?”

“I think about four years ago.”

“So, it’s been working well for four years now?”

“Yes.”

“Are we adding new functionality?”

“No.”

“So, what is the increased budget for?”

“In light of the big infrastructure changes that are coming up, I need the extra budget to develop an automated test suite.  We don’t have any for the Financial Façade, and never have.  The original development team had a few ad hoc tests they ran just before the last release, but those tests have long been lost.  There were only three guys, and they have all left the company over the years and none of them told anyone where those tests may be.  For all I know they decided they didn’t need them and deleted them.”

“But the software has been running fine all of these years?”

“Well, yes but—“

“Then it doesn’t need any tests.  I can’t approve that budget increase.  Other than that I like…”

“But that façade is critical to our online business, especially since almost eighty percent of our traffic is…”

“I don’t think we need to worry.  That piece of software, I am sure, is really simple.”

“It is, but—“

“It has also been running without a single support call for four years now.”

“That’s true.  How did you know?”

“I looked it up.  Listen, we are spending a lot of money on this network upgrade so we have to make choices.  Frankly, I don’t see why I should prioritize additional funds for testing this little piece of code.”

“Yes, but—“

Suresh dismissed Marybeth right then, with style of course, and made assurances that the decision was his and that she did not have to worry about any manager of hers who may be giving her undo pressure to “test everything.”  Calmly, and with a smile, Suresh reassured her, “Really, I don’t think there is anything to worry about.”

True to Suresh’s word, Marybeth was not blamed when the once-reliable Financial Façade started losing monetary transactions once the company tripled its customer base.  The new network was certainly able to handle the multi-fold increase in traffic that was generated by that company’s latest marketing campaigns.  Suresh was well rewarded for his efforts and went into early retirement at his peak of popularity.  Too bad he didn’t stick around to see how badly the old Façade handled an increase of traffic it had never been designed to handle.  Too bad he didn’t stick around to see the company being sued for tens of millions of dollars for the financial losses suffered by its customers.

Marybeth has been wondering why few have ever listened to her.  After all she has been an application architect for over fifteen years and has many successes to her name.  Surely, she has thought to herself, she has proven to the world that she knows what she is talking about when it comes to application development and maintenance.  Why, she has felt, is she the only person that seems to understand the difference between reliability and safety?  Why do people instead listen to golden boys like Suresh who have not practiced architecture as much as served purely managerial roles for most of their careers?  Suresh: Product Manager.  Suresh: Operations Manager.  Suresh: Chief Financial Officer.  Suresh: Enterprise Architect.  His history was available for all to see in the public records haunting the far corners of the Internet, so why place so much faith in a man who in the end really didn’t know as much about software as people assumed he did?

Marybeth knows the answer.  Marybeth knows the awful truth about human psychology that physical attractiveness goes a long way with people of either gender.  Yes, there is such as thing as a “man crush.”

For decades people like Michael and Marybeth have continued to doubt their own abilities to perform their jobs with distinction.  How could all of those other people be wrong and only she right?  Why was is that, regardless of their past successes, were the voices of fad and fancy trusted over their own voices of experience, reason and wisdom?  Recently however Michael and Marybeth have begun to stop their private self-doubt.  Others just like themselves have been coming forward, meekly at first but now in numbers, to confess their own fears.

“Wow, I’m not alone!” Marybeth said gleefully while attending a local chapter meeting of her fellow professionals who called themselves “software architect.”  I saw Marybeth at such a meeting, sitting next to Michael, while listening to a guest speaker talk about the efforts needed to professionalize the work they all do.  “In some respects,” the speaker began, “it goes against the posture of humbleness my parents taught me to respect, but we must help our clients avoid disasters in the future by forcing them to listen to those of us who have proven we know better.  Doctors do it.  Lawyers do it.  Accountants do it—all for good reason!  When uneducated and inexperienced people attempt to fill those roles bad things happen.  People die.  The innocent are jailed and the guilty go free.  Good companies fall into bankruptcy and the bad gain unfair advantage in a free market.  It’s time for us to stand up and say the same thing: when uneducated and inexperienced people attempt to fill our roles, bad things happen.  It sounds crass, it sounds elitist, but this is just the way it is.”

Marybeth raised her hand.  Always the skeptic, “So how do we know when we are doing the right thing?  How do we know we aren’t as ineffective as those people that have caused us pain the past?  How do we keep from fooling ourselves?”

The speaker answered with a smile, “You’ve already taken the first steps towards answering your own question.  First you had the integrity to ask that question, and second you came to this meeting to seek those answers from your peers you could not in good conscience provided for yourself.”

No one person started the process of dismantling the Berlin Wall.  Slowly, every East German took subtle clues from their neighbors that it was simply time to excise that ugly scar that divided Germany so.  In fact given the tight control the Stazi had over all form of communication no one person could have started that process.  Instead it happened because, simply, it was time.  Germany today has problems with reintegration, and there are surely some that wish the deed had never been done because of some of the pain that it has caused.  Most people in the world today however will agree that the demolition of that heavily guarded brick graffiti canvas is a good thing to have done whose benefits will be fully enjoyed, eventually, by the generations to come.  Similarly there is no one person to whom we software professionals can truly point to as the person who started the Software Architecture movement.  For all the short-term pain that may result from the transitioning of software architecture from a fun, youth-oriented trade to that of a mature, but safe and responsible profession, all of my peers seem to be in agreement that the conversion is needed.  It is simply time.

 By the way Michael and Marybeth are not real people, just fictional amalgams.  Does that make them any less a reflection of reality as we all have been experiencing it?  Did you think I was talking about you?