Part 2 Getting Ready - 2.3 Creating Blue Prints

2.3 Creating Blue Prints

29. An Aspiring Architect

The term ‘Software Architecture’, which originated long ago, has become predominant in the industry during the last couple of decades and this coincides with the evolution of new technologies such as web technologies and evolutionary methodologies such as Rational Unified Process and Agile Software Development in the IT industry. Software Architectures are the backbone of software products and hence software architects are very crucial to the success of software projects. Depending on its size, project teams consist of one or more architects who are responsible for providing a sound architecture for the proposed software system. Projects that involve cross-functional solutions based on multiple technologies, platforms and user groups need a dedicated team of architects in addition to a typical design team. The characteristics of software architects and their role have evolved over a period. Whether we follow distributed agile or traditional methodologies, the role of an architect continues to be significant.

A myth about the term ‘Architect’ in both Software Engineering and Civil Engineering is that an architect is an individual who brings just a good amount of technical experience in the respective engineering discipline. Though this is the fundamental requirement, an architect needs more than the technical skills specific to the project needs. The definition of ‘Software Architecture’ would help us identify the desired characteristics of ‘Software Architects’ – the not-so-new but, evolving breed of software professionals.

Various organizations and professionals have attempted to define Software Architecture. Here is a definition that consolidates many such definitions:

“Software Architecture is based on strong architectural principles and guidelines. It provides the blue print of the proposed software system and such a blue print consists of all necessary views of the software system, its components, their interaction and addresses the requirements (both functional and non-functional). Besides, it exploits the available technology with a clear strategy in order to reduce the impact on existing systems in an enterprise, remains cost-effective and delights the stakeholders.”

Evidently, it is not enough if software architecture addresses the functional and non-functional requirements of a project or product. The architecture itself has to be based on resilient principles, guidelines and it must address the long-term requirements related to the structure of the software system itself. The long-term requirements related to the structure of the software are derivable from the best-case requirements, long-term focus of the IT organization, reuse considerations, technology preference, proposed budget, wish lists and other emerging technologies that could benefit the organization.

This makes it clear that all user requirements mapped into an excellent set of use cases is just one of the inputs to the architect or architecture team. An architect need not wait until all detailed requirements are documented and use cases are identified. The architect can start his activity with initial requirements, high-level use cases, based on a set of organizational standard (or project specific) architecture goals, principles (typically a set of Dos and Don’ts) and guidelines, keeping in mind the clear picture of the customer’s IT infrastructure, mission and vision. This is because an architecture that is not aligned to customer’s IT infrastructure, mission and vision would prove itself to be fruitless and evolve as a major risk for the project as well as the organization as a whole.

In my opinion, Software Architect is a professional who is not only broadly technical with deep experience in certain technologies but also very good at soft skills especially in the areas of business communication, conflict resolution, self-expression, emotional intelligence, and team skills. When an architect presents a product architecture to team members, there could be conflicting issues, interests and alternative solutions. The architect needs to have strong skills in putting his architecture across by means of presentations or discussions. She has to be open-minded to encourage, understand and appreciate suggestions. Meanwhile, she must be time-bound and decisive to make his team as well as her stakeholders understand the rationale behind the proposed or renewed architecture. In addition, she must carry the right level of self-esteem and feel proud of the final decision and exhibit ownership throughout the product life cycle.

In summary, software architects need to be experienced in various areas including core technologies, peripheral technologies, application development & implementation and a variety of soft skills. Software architects need to hone their skills and build expertise to research and understand emerging technologies, technology trends, as well as client’s IT infrastructure, mission and vision. Finally, they need to have necessary expertise in identifying and using software processes, tools and techniques in order to architect the software system, document the architecture with required granularity (with APIs and code samples), communicate it to the project team and be a mentor for the team in implementing the system. With these qualities, this new breed of software professionals can definitely be identified and admired as visionaries for the software project and team they are working with!

Are you an aspiring Software Architect?

*-*-*-*-*

30. Which Architecture?

We have heard of terms such as application architecture, business architecture, cloud architecture, data architecture, enterprise architecture, fault tolerant architecture, hardware architecture, information architecture, knowledge architecture, network architecture, performance architecture, security architecture, software architecture, solution architecture, technical architecture, web architecture, and so on. 

Our focus is on software architecture.  Let me share a definition of software architecture from the book ‘Software Architecture in Practice (2nd edition)’ by Bass, Clemens and Kazman.

“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.”

*-*-*-*-*

31. Decisions Matter

Here is another definition by Grady Booch, Philippe Kruchten, Rich Reitman, and Kurt Bittner.

Software architecture encompasses the significant decisions about

•       the organization of a software system,

•       the selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements,

•       the composition of these elements into progressively larger subsystems, the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition.

Software architecture is not only concerned with structure and behavior, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and trade-offs, and aesthetics.

Decisions are the foundations to creating great architectures.  Beyond skills and expertise architects need to perform well, remain resilient, be clear and prudent and make right decisions at right times. It is more than awareness, admiration and lip service.  Are you ready?

*-*-*-*-*

32. Who Have You Worked With?

Software architects come in different categories.  There are software architects who limit their profession to architecture definition either by creating slide decks or short documents with block diagrams.  There are software architects who leave the team before the development starts. They appear for a short duration, play their role of delivering architecture definition – they do it with authority, and move on to their next project. They treat architecture as relay sport.    The third category is architects who play part-time role in multiple projects.  Architects in this category are not accessible to team members.   Architects in the fourth category are the so-called glorified coders go get the title because of their perseverance.  They are passionate but lack skills.  The fifth category of architect consists of ‘tech savvy’ managers who are terrible in project management.   Probably they were given this title because of their technical knowledge.  Architects in this category no longer design or code or live with the premise that they are too busy to code.  However, they know multiple technologies and solutions.  They can talk in meetings and voice their opinion.

The next category is the ‘had been there and done that’ architects.   They are experts. They nurture architecture and design competency in teams. They believe in empowerment. They stay with the team and participate in engineering activities such as coding, deployment, performance testing, etc.  They are valuable and they are rare to find.

*-*-*-*-*

33. What Do Architects Deliver?

What do architects deliver?  Do they deliver a presentation or a document with block diagrams or guidelines or all these?   Do they go beyond architecture definition and contribute to architecture implementation?  Do they write code or deliver various sub-systems and components that constitute an architecture framework?  Do they mentor team members and help them deliver great products? These questions make us reflect on the ground realities on what is delivered by architects.

The answer to this question is not going to be the same in all projects.  Try to find your answer – an answer that suits your project. Make it happen!

When a product or application is delivered to customer or rolled out in production, production support, sustenance, technical support and consulting teams play a significant role ensuring customer satisfaction.  How do architects contribute to these teams?  Do the activities or contributions of architects add value to the work life of someone who is involved in production support, sustenance or technical support or consulting? In order to debug or to understand the regression issues, do we get an up-to-date schematic or map that improves the efficiency of such activities?  Or have we let these teams wade through thousands and thousands of lines of code and find a solution?

In his article published in the September/October 2014 issue of IEEE Software titled ‘Driving Agile Architecting with Cost and Risk’, Eltjo R. Poort.  says “Decisions are your main deliverables.  Thus, the role of the architect is to make sure that the group’s decisions are consistent across the whole solution, even when multiple teams are working on it simultaneously.”

Decisions!  Yes, a whole lot of decisions right from decisions related to the basic building blocks, trade-offs, integration points, interfaces, dependencies, data storage, performance, scalability, deployment, cost, maintainability, and so on.  Decisions are the main deliverables.  Also, architects need to have a backlog of architecture concerns and convert them in to decisions in a timely manner.  This is a good practice to make sure that nothing is ignored or forgotten or assumed. 

Had you been part of large-scale agile projects? Did you project have a team of architects? If yes, what did they deliver? What more did you expect them to deliver?

*-*-*-*-*

34. Set on Stone?

What comes to your mind when you stand in front of a monumental building like the Taj Mahal and wonder its gigantic view? Terms such as ‘structure’, ‘architecture’, ‘design’, ‘aesthetics’, etc. come to your mind.  I am sure you observe the thick walls and huge doors, their precision and aesthetics, etc.  You want to know about the history. You go closer and look at the tall gates, windows, and numerous finely carved paintings.  You appreciate the designs of various parts of this monument.  There is a place and purpose for every component. The entire structure has been architected and planned well.

It is not wise to compare civil engineering with software engineering. However, it is wise to view such monuments and appreciate the takeaways from such alternate sources.   There can be many takeaways.  The number of takeaways is left to your imagination.

Obviously, I am not going to stretch this beyond limits.  This is because our IT world is different. It is dynamic.  There are moving parts.   Products and applications witness many upgrades of operating systems and databases. Interoperability is essential in many cases. That is not it.  Scalability, performance, security, fault tolerance and many such non-functional requirements cannot be given a slipshod attention.

Do you think ‘Big Up Front Design’ (BUFD) done by architects or designers is set on stone and does not change?   Is change cost-effective when you do BUFD?  

Do you think the architects of the Taj Mahal or any other monument for that matter,  handed over their specifications to the next rung of workers and moved on to other projects?   Does the initial architecture of this monument emerged or underwent changes when the construction was in progress?  Were new ideas and design elements accepted and put into practice?

I think yes.  Architectures emerge!

*-*-*-*-*

35. Different Schools of Thought

Architects from the traditional school of thought live in the world of ‘architecture thinking’.    The script that plays in their mind is, “I am an expert.  I will convene a meeting with some of the senior members. I will decide and suggest the right things.  I believe in Big-Up-Front-Design (BUFD).  Architecture is a complex, esoteric entity.  I am autonomous. I am up in the org hierarchy. Coding is what I used to do several years ago.”

Agile practitioners believe in ‘agile thinking’.  The script that plays in their mind is, “We do ‘just enough’ architectural activities. We don’t do BUFD.  Often, BUFD results in waste and rigidity.  I am here to work with my team members.  I am their mentor.  We believe in emerging architecture and design.  Our approach is to create systems that can accommodate changes in a cost effective manner. For this we will work as a team to evolve the right architecture or design. We will provide the right diagrams and documents as and when necessary to help our teams.”

Architects in agile teams are not confined to their desk or cabin.  They work in open space with team members throughout the project.  They nurture young architects through mentoring and working together.  In mature high-performing agile teams, everyone plays the role of architect or designer.   In agile world, architecture and design are not dead!  Agile projects need architects and designers who follow agile principles.  Architects and designers can add value in agile projects.

*-*-*-*-*

36. 4+1 View

Sometime in 1998, I read Philippe Krutchten’s white paper ‘Architectural Blueprints—The “4+1” View Model of Software Architecture’.  I found it very practical and timeless.  Like every other writing that revolutionized our industry, this paper is a must-read for all IT professionals.   This paper is not limited to object-orientation or Rational Unified Process. It is timeless!

Do a search on “4+1 View” you will find it on the web!

Try to think through these 4+1 views of two or three enterprise projects that you worked on recently.  You will understand these and connect all these pieces well together.  In addition, you will start recommending this paper to your colleagues.

*-*-*-*-*

37. SOLID Design

SOLID is an acronym that stands for five design principles.  These design principles are worth knowing, practicing and remembering.  Here is the list.

1. Single Responsibility Principle (SRP)
2. Open/Closed Principle (OCP)
3. Liskov Substitution Principle (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)

Robert C Martin, popularly known as Uncle Bob has articulated these principles in his white papers.  These are worth a read.  Understand these principles, apply them do improve the design of your current project, and share what you learned with your teams.

These principles will provide a very good foundation to your design skills.

*-*-*-*-*

38. Developer’s Wish

Years ago, a young developer came to me for a job interview.  He had two years’ experience in software development and maintenance.  During the interview, I wanted to understand his career goals. So, I asked, “Well, how would you like to contribute in your next project? What are your career goals?”

He was spot on! He said, “I have done programming for 2 years. Now I want to do design for couple of years and master design. After that I want to go up in the value-chain and become an architect.”

Our interviewed continued with some more questions and it concluded.

I have come across several developers with an excruciating yearning to become designers.  I am sure you have come across them too.  When they become designers, they want to rise up in the value-chain and become an architect! They come with high aspirations.

Are you one of them?  Do you know the truth?  Programmers or developers are designers.  They see and feel the design. They can learn and give feedback.  They can appreciate, relate and connect with the design and architectural elements.  They can do this when they see the larger purpose and possess the ability to learn.

This transition is a continuum.  In every developer, there is a designer.  Moreover, every designer or architect there has to be a developer.  Those who embrace this continuum are adored by their team members.  They go beyond notations and block diagrams. They write beautiful code!

Understand this continuum and set your goals if you want to remain a techie.  This is because, it is impossible to renounce coding and become a designer or architect.

*-*-*-*-*

39. No Room?

“This project is different. There is no room for design. Designs are provided by another team that sits in a remote location. All we do here is to fix defects, or enhance features or add new features.  There is no scope for design.”

This is what I heard from a team member.  My intent was to understand if the team members are aware of the architecture and design elements of the application under maintenance.  What I heard made me think.

Refactoring is not new to us.  Refactoring is about improving the structure or design of an existing program. It is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. 

Refactoring is to improve the design of the existing code and the overall code quality. Often, refactoring precedes a program modification or extension, bringing the program into a form better suited for the modification step. Sometimes, refactoring is of anticipatory nature -- bringing a program into a nice shape after making it work, in the hope to facilitate reuse and maintenance.

'Refactoring' and 'adding new features' are distinct activities.   Sometimes, we say, "Let us refactor the code to add these 2 new features".  This does not mean 'Refactoring'.  It means enhancing code to accommodate new features.   Therefore, adding new features is not ‘Refactoring’.

Every software engineering team (irrespective of the methodology followed) must invest time in refactoring. When engineers do refactoring, they will come up with feedback on the design.  It is a great learning experience! When you go back to customers with brilliant inputs on design improvements, they are going to love it!  You are going to feel on top of the world!

In fact, refactoring does not happen in a planned manner in many software projects.  It is unplanned and it happens in bulk during integration testing or acceptance.  Very unfortunate!  

Refactoring at regular intervals is the right thing to do!   Do you practice refactoring?  Do you use any tools for this?

*-*-*-*-*

40. Architecture and Design - A Done Deal?

When is the last time you saw an outdated architecture or design document? Who created it? Who reviewed it? How many read it? Why has it become obsolete?

We must know Lehman’s Laws of software evolution to answer these questions.  Knowing these laws will help us become aware and less frustrated with the dynamics of architecture and design.

According to Lehman’s Law of ‘Continuing Change’ a software product or application that is used in real-world environment must change – else it becomes progressively less useful in that environment.  This is one of the eight laws. 

Architecture and Design is not a done deal.   Read the paper Laws of Software Evolution Revisited by M.M.Lehman to know more about Lehman’s Laws. Google will help you find it!

*-*-*-*-*

2.2 Discerning the Magnitude                    Table of Contents              2.4 Crafting Considerations