Software Architect — Journey

On this article, will cover some points every Software Architect should be aware in their professional career.

1. Who is Software Architect?

Software architect is a person who define the way to build a software platform/product with in the organization/project (depending upon the scale of the organization)

Developer Vs Architect

Developer knows what can be done to create a platform/product. But an Architect should know what should be done to create a platform/product in the right way.

Different types of Architects

Software Architect — Sometimes they also knows as Technical Architects in some organizations. We will cover more characteristics of Software architects in below section.

Infrastructure Architect — These guys will design the infra structure required for running applications created by the development teams. They will manage the topics like Virtual Machine, Servers, Networking, Storage, Maintenance of the Server OS, Networking of the Servers and lot more in that scope.

Enterprise Architect — These guys will be one level upper from a software architect. They will work more closely with CEO, CTO to streamline the IT process with in the organization. They will not be directly involving with project level architecture need or development mostly. But they will be enablers/validators for the same.

What should we expect from an Architect

Architect should deliver an application which should have the following capabilities

• Fast
• Secure
• Reliable
• Maintainable

Architect Should Code ? (Controversial question)

Its purely based on my view, he should know how to code, even if he is not writing code for the same project on delivery basis. This will give more confidence for the architect to take decisions and support the developers in development process.

He should be able to create some PoC projects to test the trustworthiness or usability of the new technologies. The more you keep in touch with coding, the more granular you can go in the architecture or development process.

Prepare your mindset

Being an architect, you should always consider the business benefits of the application, instead of being a technical expertise. It will sound easy, but its not, this will help you to understand the system in the right way and you can design and take decisions based on the vision instead of short term targets. You should think from the end user view also get more clarity on the same

Prepare the Goal Statement — You should define the goal statement for the project, this should clearly indicate the business benefit of the application.

2. Process Flow

What all I should do as an architect when I receive a new project. Make sure to get each level approved from the business to align properly.

2.1 Define Functional Requirements

• Define what the system should do., like business flows and services.
• You will get the same from Business Analyst / System Analyst or who will be working closely with the business to refine the requirements.
• Grab as much as possible and get all the possible queries clarified at the earliest.
• Make Sure to formally agree between Technical and Business team on the same.

2.2 Define Non-Functional Requirements

• Define what the system should capable to do
• Define all Technical and SLA related requirements like the performance, response time, number of users, load, data retention, data volume
• Make sure to find the exact numbers instead of general terms (like performance should be ‘fast’, data retention should be ‘as much as possible’, response time should be ‘as fast as possible’)
• key NFR parameters that should have an answer before designing architecture is performance, load, volume, concurrent users, SLA, data retention
• Always consider the extreme cases on all these numbers
• Mostly we should define this from the business or system analyst.
• Sometimes this will be more important than the functional impact as the same can make the architecture decision upside down.

NEVER START ARCHITECTIRAL DESIGN WITHOUT CLEAR AND APPROVED NFR REQUIREMENTS

2.3 Define Components

• Define the functional components for the application
• It will be purely non technical process,
• Think from client’s client perspective

2.4 Choose Technology Stack

• Choose which type of application you are going to build like desktop application, web application, mobile app, and more
• Choose the best technology for the application
• Consider the Technology community support, technical support from the company, technical expertise on your team etc.
• Its the critical part as s an architect
• Get more inputs from young minds on the team also, this will help to get some scenarios which you dint thought of
• If you have team of architects within the organization, plan an architectural debate if possible to get more inputs and thoughts

2.5 Design Technical Architecture

• Design the architecture
• Create multiple sub diagrams based on the complexity if needed.
• Always consider a high level and detailed diagrams on both functional and technical components.

2.6 Write Architecture Document

• Consider the document should be shared across technical and non technical stakeholders, at least the section which describes the high level flow should be understandable to every one.
• Make sure that the document is a living document and you keep updating the document based on the updates happen to the system.
• Always keep updating the document with new changes, instead of removing the old implementation details.

2.7 Development and Support

• Now the team will be ready to start the development
• Support your development team on the development stages

3. Choose Technology Stack

3.1 Application Types

Please find some sample application types, there can be more or combines options based on your need

• Desktop application
• Web Application
• Web API
• Mobile Application
• Console application
• Service applications

3.2 Considerations

• Critical Step on the process
• Hardly irreversible process
• Include more team members or pear architects in the process
• Document as more as possible including the comparison if any or any justification to choose the same over others and so on
• Technology should be capable to serve your functional and non functional requirements
• Technology should have both community and enterprise level support, you can check the community support using websites like stack overflow or google trends
• Consider fresh technologies only after deep analysis as the community support and long term plan on the same will vary based on its success.
• be unbiased on the selection process.

3.3 Technical Considerations

To be a good architecture, the same should adhere to below capabilities.

• Scalable — Should scale based on need and cater the users without any deviation on performance
• Manageable — Should have monitoring systems in place to actively monitor the application heath, logs and other metrics based on the relevance
• Modular — Modules or services in the application should be able to update without affecting others
• Testable — Your application should be testable and should write unit tests to cover maximum test cases with maximum code coverage possible. Should include Integration tests to test the entire data flow.
• Automatable — Consider automation on all possible processes

3.4 Software Components

Its a piece of code that runs a single process of the system, We should plan and design below two architectures

Component Architecture

• Deals with the inner component communication
• Components should be layered — Presentation-UI, Business Logic-BL, Data Access layer-DAL
• Layers vs Tiers — Layers will be present with in the same component or service, but tiers can be present in different systems via network connection
• Data should pass the specific flow only. UI>BL>DAL.
• UI > DAL or DAL >BL is considered as wrong directional, never do the same to interrupt the flow
• Layers allows you to loosely couple your code
• Exception handling — Never Pass the Exception Object from DAL > BL, this will lead to security threads, always respond with generic exceptions
• Catch exceptions only if you have anything to do the same, don’t use if its necessary. use exception catching only when you have a genuine reason like rolling back some transaction, retry the process, wrap the exception and more. Make sure to catch specific exception instead on generic “Exception” class
• Try to wrap the try-catch block as small as possible to specific area (don't write ‘try’ on the beginning and and ‘catch’ on the end of your method)
• Make sure to use Interfaces and dependency injection, never use object initialization with “new” keyword in your services, as that may lead to major code change in future if any minor change on the same.
• Define Naming conventions and stick with the same from the beginning, try to use analyzer tools with your editor to force the developers to stick on the same.
• Define logging process — Log properly — Don't log unnecessary information

be SOLID

don’t get confused with the principles, just refer the some links to get some inputs link

Single Responsibility principle —

• Every class or module or method should have only one responsibility

Open/Closed principle —

• Software entities should be open for extension and closed for modification
• Use class inheritance and plug in mechanism to make the code flexible as possible

Liskov Substitution principle —

• Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.
• It deals with behavioral subtyping
• Your updated methods should adhere to its previous behavior while updating

Interface Segregation principle —

• A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.
• Separate out the interface to increase flexibility

Dependency Inversion principle —

• Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.
• Use dependency injection

Design Patterns you can consider

There are so many designs pattern and ways to develop the code, here am refereeing some of the you can consider

• Factory Pattern
• Repository Pattern
• Facade Pattern
• Plugin Pattern
• Or combination of these..

System Architecture

• Bigger picture of the application
• Here we should design the way how components communicate
• Other matrices like scalability, redundancy and performance
• Loosely coupled services, you can use micro-services.
• Use Gateways or Directory Services to connect between services
• Consider stateless applications when possible
• Prefer scale out instead of scale up
• Prefer load balancing
• Cache frequently used and rarely modified data using in-memory or distributed cache services or platforms
• Consider message based architecture when possible
• Centralized logging and monitoring solutions
• Should use “CorrelationID” to identify the flow
• Should consider planning the disaster recovery plan also. In some organization the same will be managed by the infrastructure team, but in some others its not

3.5 External Things

Consider below points also

• Project deadline
• Team’s skillset and learning curve
• Cost

4. Write Technical Document

Writing document about is one critical job as an architect. Now lets consider some content you required to add in the document

4.1 Audience

Consider that the document should be give deal to all the stakeholders in the organization. Its obvious that some portion of the document will be more technical and technical people can understand it, but the document should contain the content that servers for all audience as much as possible.

4.2 Document Contents

4.2.1 Background

• Pages : 1–2
• Audience : Tech team and management
• Describe the system, reasons for the change, business benefit and similar content
• This will help to validate the view of Tech team with the business

4.2.2 Requirements

• Pages : 1–2
• Audience : Tech team and management
• Should include both functional and non-functional requirements
• Should be accurate and specific with numbers

4.2.3 Executive summary

• Pages : 3–4
• Audience : Management
• Should be readable for management stakeholders, use less technical terms.
• Make it crisp and clear as the summary should give an overview about the project and its benefits to the organization
• Consider adding high level business flow diagrams

4.2.4 Architecture overview

• Pages : 5–15
• Audience : Tech team
• Should provide high level view of the architecture, don't go deep into individual components or sub process
• Use high level business flow diagrams or logic diagrams only
• Should consider a detailed write up about the flow

4.2.5 Technical Components

• Pages : 15– any number
• Audience : Tech team
• Should provide more granular information as possible
• Cover technologies used and include if any comparison already done during the process for choosing the same
• The same can be sub divided based on the components like Data store, backend, front end, communication, protocols and more.
• Go as deep as possible
• Consider it as s living document and keep updating the document on regular basis
• you can include the components scope, role, tech stack, component architecture and also development instructions also

5. Soft skills

• Listening — Should listen to team members, don’t behave like you are the smart guy among the room
• Accept Criticism positively — Be professional, don't attack back
• Respond to questions based on the user — Use technical details if you are answering to technical guys. Use non technical answers to management.
• Deal with organizational politics — You know what I meant..
• Grab some public speaking skills

I Hope this will give some idea for Architect Journey.

Keep learning, keep coding.