Digital Journey

People like things visually appealing. People use things that fit the purpose. If both come together, and the timing is right, and with some luck added, the innovation takes off.

When something is successful, the architect is usually praised for the appeal, and less for “form follows function or simplicity of internal structure (a.k.a. engineering)”.

In software, the visual appeal is the user interface design and interactions. This is a specialized field of User Experience (UX) designers. Practitioners of this art form, are the front-end architects. The skill can be learnt by any user interface (UI) architect or engineer, however, the combination skill (UI + UX) is much rare. There are specialized UX companies, that offer prototype UI  (in a given technology – HTML5 etc.)  development with the help of developers. Such prototypes are great for formative testing with customers, however, architects and engineers of UI software have to structure and implement (construct) the software to meet other quality attributes (MVC Pattern, Connecting Data Sources, Re-usability, Modular Designs, Performance, ….).

The role of an architect in software (unlike civil or construction fields), is less about the visual appeal, and more about the internal structures of software. Even in the civil or construction fields, such roles are specialized (interior designers, industrial designers, exterior designers, etc).

A master (software) architect partners with UX designers, to make UX quality attributes a top priority for the project.

Selecting (making the choices) of the patterns and technologies to be used, in agreement with the projects scope (cost, requirements, resources), is where the software architect spends most of his/her time. Specialized art forms (like UX) are executed in partnership with UX specialists.

That said, I don’t intend to say that there is no “art” to architecture. Indeed there is. However, the other side of the coin (selecting, organizing, executing, partnering, modeling, validating, etc) is more significant.

Software Architecture is a Software Engineering Discipline. It’s a creative field in an engineering sense. Given that engineering is itself an artistic (sometimes deliberate) field, with greater emphasis on application of knowledge and professionalism for trade.

It’s taught & preached. Make wise choices. Left-right look, Prediction, analytics, …

Architect’s have an interesting job of making choices. They could use intuitive thinking, logical thinking, critical thinking or design thinking.

While making choices, it’s common to choose a trending technology or a trending pattern. Developers want it, managers can hire people who want to build it, and you could become an expert at the use of this shiny new thing, and would be a good thing to put on your resume. Everyone wants new. Until the promise of value fails. It’s then a ‘Pivot’.

Pugh matrix’s can be gamed by changing the weights. There is influence of the environment, corporate, community & industry on the choices; and this process is influenced by feelings/sentiments and not only data. Like Wall street or Nifty! A successful architect is deemed to be credible, and the choices made by him/her, or a recommendation coming from him/her, could become significant. A successful business relationship between your company and a partner, could become significant. Biased by design.

Also, given the explosion of technology choices and patterns, its difficult to keep track of the changes, direction, and value proposition of all such stuff. This is just the side effect of innovation and industrialization. Multiple choices results in commoditization, and drives down the costs.

Example: Smalltalk vs. Java. You have to know both to compare, and as a result you could land up in the Smalltalk camp or Java. Smalltalk is very powerful, and early adopter of ideas, and adopted in the academic circles. However, Java has been more prominent in commercial circles. So, how do you make a choice?

One way is to ignore, and become lazy, and procrastinate. Since, anything in this world can be justified, you could say that this choice is not architecturally relevant, and adopt the polyglot trend. Alternatively, you can criticize (or critically appreciate) the adoption of polyglot, collect data to show the perils of doing so, and drive a corporate initiative to standardize (naming, blaming, shaming to drive compliance to standardization).

Sometimes, if your choice is not an industry consensus or trend, the environment (managers, consultants, developers) will be pushing back on you to adopt (Mr. Architect, you should take some risks! *)

*at your own risk

Since, architecture is about making choices and defining a structure, two architects could come up with two different (but similar) architectures. Each one can claim that their choices are data driven, time tested, and the best for the business.

So, how to make this work?

The only thing that I have seen “work” is to have “one” decision maker (not necessarily by hierarchy) for a choice. The decision maker is free to change decision downstream without being killed (named, shamed, ousted, …). The decision maker should not be continually influenced (or threatened), but informed. The decision maker could be the person doing the work to make a choice, or collecting inputs from various experts to make a choice. People who disagree with the decision, should have an open environment to disagree, provide inputs, challenge the status-quo. This holds true for those up in the hierarchy, or down in the hierarchy, or sideways in the hierarchy. In all cases, once a decision is made, the team/organization should support & pursue. This is culture.

In general, people are good. They like to make the business successful. Hence, they like to make decisions using intuitive, logical, analytical, or critical thinking. Culture, will get all the pieces to fit gradually.

Therefore, there should be only one architect for a choice. Make a decision, move on. If it’s wrong, talk about it and fix it. If it’s right, talk about it, adopt as best practice.

“Architect must code. Manager must code. Scrum Master must code. Tester must code. Product owner must code. Developer can become architecture owner. Developer should become tester. Developer must understand customer challenges”

The way the debate goes, it almost seems like everyone is trying to do someone else’s job. And, this behavior gets justified as self-organizing teams.

In a real world, people have mustered skills and aspire to learn new skills. This is true for an architect as well. It’s very rare, that we are able to assemble the perfect team. Mature @ t=0.

It’s important to pull your weight as part of any effort/job. If coding is your strength, do it. If customer engagement is your strength, do it. If inspiring people is your strength, do it. If making choices (trade-offs) is your strength, do it. If you have multiple skills & you are ambidextrous, do it (lucky!). Just don’t burn yourself out, doing it all.

If the challenges for the team are not architectural (i.e. most architectural choices are made and time tested, or, team is mature and governance is not required), then the architect needs to pull his/her weight to address the challenges. This may mean coding, testing, and/or selling. If this type of work is not interesting (or boring or offending), it’s time to change than be a burden.

If the challenges for the team are realizing the architecture, and they look up to the architect for help, the architect MUST code to show how to get things done. It’s OK to ask for HELP, if you believe the architecture is right, but you don’t have the coding skills to get it done. It’s part of learning journey.

Winning is important. Need to give yourself permission to do the right thing. Sometimes, the right thing is to go up the Ivory Tower and preach. Sometimes, the right thing to do is go down the trenches and teach.

It’s a trade-off.

In this new brave world, anything can be said, done, and justified.

This sentence is complex. English! My god. Such a complex language.

• Continual = repeatedly (say the tv show is running continually)
• Continuously = non-stop (say the tv is running continuously)
• Emerge = come-out (say a baby bird emerges from egg)
• Evolve = grow-into-a-new-state (say a caterpillar evolves to a butterfly)

So,

• Continual emergence = A new architecture showing up repeatedly (every sprint or PI) for life.
• Continual evolution = A new architecture after emergence, evolves repeatedly to adapt to repeated change in requirements. The architecture continual evolution stops, when requirements continual evolution stops; i.e. Product is mature & moving to EOL (end of life)
• Continuous emergence = A new architecture showing up every day (or second) for life.
• Continuous evolution = A new architecture after emergence, evolves non-stop to adapt to non-stop change in requirements.

Practically speaking,

•  In the early stages of the project, the change in requirements that impacts architecture can be  continuous. Architecture also emerges and then evolves continously.
• In the later stages of the project, once requirement volatility has been addressed, the  architecture remains more-or-less constant (gets cemented) and changes are infrequent. Architecture is evolved continually to address new requirements that would have emerged requiring architectural change. This architecture change could be a costly (impact regression, $) project.
• The software does reach a state, where change in architecture, is hard to address certain types of requirements. At this time, a phoenix (re-birth) or hydra (supplement) type strategy is required.
• The software finally does reach a state, where disruptions and innovations in the industry, would have disrupted the value proposition, or architecture. This is the time to EOL the product.

In Summary, though anything can be done i.e. continual or continuous emergence or evolution of architecture throughout the product life cycle, it’s not the norm. Emergence happens early, evolves continuously till proven, has a few (less than 3) major continual evolutions during the life of the product.

Having the power to do something, does not mean it’s a responsible thing to do!