Change Impact Analysis or Impact Analysis (IA) is the process of identifying the potential consequences of a change, or estimating what needs to be modified to accomplish a change. In software engineering, there are two normal types of IA: “Traceability Impact Analysis” and “Dependency Impact Analysis”. The input of this process are the requirement or need that cause the change with the definition of that need or requirement and the current picture of architecture and its context. And the output of this process is the list of the impacts or potential impacts.

In the scope of software-intensive system architecture, we usually refer to Dependency Impact Analysis (DIA) as Impact Analysis which is the scope of this post because we will normally use Traceability Impact Analysis (TIA) as a starting point for the change in existing requirements, scenarios, functionalities, and features. And although there are also other types of impact analysis but it is not in the scope of this post.

Static structure,  dynamic structure, and quality-attributes views of the architecture will be used to identify the potential impacts by reviewing them against the scenario. And once we get the list of the impacts, we will then submit it to review with team and stakeholders.

At first (and most important) level, we will list only the impacts that happened on the whole IT system:

1. system logics (both data and processing)
2. information architecture
3. software architecture
4. hardware system architecture
5. networks and infrastructure.

Then we will drill down into more details at detail level:

1. Detail software design and implementation
2. Detail OS and software framework or libraries specifications
3. Detail hardware and driver specifications

After having the list of impacts on the IT system, we will then move to investigate the second level impacts on the processes or procedures of managing the IT system:

1. Release and distribution process
2. Installation, patching and uninstallation procedures
3. Backup, restoration, and reconciliation procedures
4. Environment/site failover procedure
5. QoS and SLA
6. Support and troubleshooting procedure
7. Monitoring and instrumentation procedure
8. Development and QA process/methods
9. Etc.

Once we done with the second level impacts analysis, we can then submit the report to the chief architect and enterprise architect to review and consult with the business to evaluate and analyse the impacts at service and business level in order to review with the business side as necessary.

One biggest question in designing the architecture of a system is because the word “simplicity” is rather relative thing than having hard-and-fast rule to define it. According to that, I think we also have some criterions to define the baseline here:

1. First of all, it fulfils the MANDATORY functional requirements.
2. It also fulfils the MANDATORY non-functional requirements.
   • Frequently, we tend to jump right into the problem before knowing the exact threshold of each non-functional requirement.
   • Please make sure that we already have the list of prioritized non-functional requirements with its expected values that are really *NEEDED*, not fancy features please.
3. There is nothing to put out, otherwise it will break or not meet some of mandatory requirements.
4. It can be developed, tested, distributed, deployed, maintained, managed, and support by using typical knowledge, tools, and processes.
5. Sometimes, sometimes, the real problem is hidden in politics.

This list does not guarantee that we can get the best or simplest or most optimal design in one shot, but it is a reminder for us to always review it while we are designing something.

Having said that, sometimes, we also have to take some other criterions into account too. Somebody may argue that it depends on what type of the system we are designing is e.g. life-critical or safety-critical system, system that directly accessing to the precious resources, … , in such situations, a little degree of over-engineering maybe acceptable or even more preferable, which I also agree with it in some extents.

There are several areas to touch when we start discussing about producing the flexible architecture and we may have several posts back to business side if we not put a scope to this dialectic. So I decided to put aside the points regarding the whole product delivery process, development process, architecture review process, and requirement management process, and let’s concerns on the technical design topics which will be a lot easier to keep it practical and be able to apply to our job immediately:

1. Have good prioritized requirements or scenarios, so we know what are the core or value-added functionalities of the service.
2. Clear and concise traceability from scenarios and features down to the chain of system components.
3. On/off configurations and scripting for non-core features.
4. Stateless and horizontal scalability are still the most preferable.
5. No distributed transaction.
6. Decoupling the business process logics from the processing or workers.
7. Decoupling the service interface from the service implementation.
8. Modularity and composability
9. Self-containment and isolation of the services/modules.
10. Interoperability and open standard protocols.
11. Contract-driven design for both data and interfaces.
12. Loose-coupling.
13. Weak Typing.
14. Prefer stateless over stateful connection.
15. Fire and forget communication.
16. Event and message driven.
17. Not so realtime, please.
18. Cross-cutting and common concerns.
19. Dependency management and injection.
20. Make sure to have the complete test stubs.
21. Easiness in deploy/undeploy/re-deployment is always preferable.
22. Virtualization and cloud computing.

Note: Although this list is not prioritized in any order because it could be vary from project to project, but it sure is a good starting point for reviewing our design and even apply it immediately. The flexible architecture provide us a lot of benefits both during both creation and modification times. During creation time, we can plan and develop the system in the distributed agile mode because we can adopt the “Just Enough Design Upfront” concept to analyse the context and create the skeleton architecture or schematic design to use as a common high-level picture among the distributed teams. We will then define the contracts (plus some important specifications) and review it together through the interaction simulations per each scenario.

In order to let the architects to create the pictures to compose together, requirement/scenario management and synchronization between the product managers is critical.

After we have the same clear common high-level pictures, scenarios, interactions, contracts, and responsibilities. Each team then start their works at full speed. Be aware that some teams may have to provide the test stubs or mocks to other teams or even do the prototypes, while some teams may be not. So planning and orchestration skills of the project managers is the key.

I’ve been thinking about this during my free times for more than a month. Since our development teams are exciting and eager to moving itself to agile development process while we, as the architects who have to take care a lot of many tasks and needs from several stakeholders and projects, have to take care of them and response to their demands in order to let them run and enjoy their works.

It boils down to a conclusion that we may also need to change our process or method of working too. In Bangkok side, we have to be able to response to the needs of development teams along with other stakeholders while keep it in balance at the same time. So we need to make our method of working more flexible and clear.

Architects, have to do the architecture design and govern it through the implementation to deployment and support and maintenance. While in the agile manifesto, dev tends to prefer and trust in thinking and prove it through testing and refactoring (to make “Emergent Design”) than what they call us “Big Design Up Front”.

In order to works with teams that are trying to do agile process, we need some guidelines or rules in making decision about what requirements or architectural elements that are needed to be passed through architectural design process strictly or we can leave it to be solved at development level. Here are those criteria that I can think of for the moment, the more or higher those elements or requirements are like these concerns, the more it has to pass-through formal architecture design process, prototyping, and governance.

1/ How much this requirement or functionality or module or project is:

• Less clear and concise
• Critical or important
• To access, feed, inject, process, or manipulate something into the critical system or the system that is a single-point-of-failure of a system
• Complex
• Risky
• Cause impacts to others
• Be the foundation work for other works/teams
• Urgent
• Distributed processing
• Heavily connected to many parties such as the integration works
• High cost
• Quality attributes are highly concerned
• Frequently change the responsible product managers

2/ How much the development teams used for this module or system or functionality or requirement are:

• Less skilled
• Less mentally matured
• Less process-wise matured
• Distributed across time-zones and spaces
• Politically divided
• Limited in resources
• Frequently change their staff

3/ Technology and tools

• Less mature
• Low activity (for open-source technology)
• High licensing costs
• Less vendor support
• Low and slow response in their discussion boards (for open-source technology)
• Hard to do maintenance and high TCO
• Unclear between technology choices
• Vendor’s status is uncertain

4/ Budget for your project

• Limited
• Uncertain and need long time for approval process

5/ Project and timeline

• Strict and rigid
• Tight
• Uncertain
• Frequently change project managers

6/ Environment and infrastructure and its management

• Less mature
• Limited
• Distributed
• Concerns in security
• Need long process for changing something

Other things than this, I think we can leave it to be solved or try at development level in order to let them do development faster and more agile as they need, while we will join them in the potentially architectural-related refactoring and emergent design discussions, we will then gather the results and feedbacks back to do formal design and communication for formal reviewing to make some formal change in the design as appropriate.

The good signs that we already have are, we are starting to do “Incremental PIA” and self-assessment process on top of the formal PIA and technical governance review process. So I think these ideas could fit together.

I will share my idea with you all about the whole process in architectural design iteration in order to work with across smaller development cycles later.

What do you think?