IT architecture in practice

Work work…

I work in IT at Colruyt Group, as I already mentioned in my Scratch presentation post. To be more specifically, I work as an IT Architect (also known as a Software Architect).

It’s often difficult to explain what this exactly means in practice, so I’ll give an example using my automatic roller shutter project.

Context

A couple of days before we went away for a trip, I got the idea that it would be nice to give our house an inhabited look during our absence. So I wanted to automate my roller shutters to give that impression.

In a typical project, you’ll have business users that come up with requirements. And various people to realize your project (developers, analysts, an architect, a project manager, …). For this specific case I took up all these roles, but I’ll focus here specifically on the IT-architect role.

Architectural drivers

The architectural drivers are the inputs that will shape your architecture.

The requirements

The (functional) requirements were actually quite simple:

• REQ01: The roller shutters should automatically go up and down (up in the morning, down in the evening) at a predefined time.

Constraints

There were also a couple of constraints. The resulting IT architecture should take those constraints into account, otherwise the resulting solution is not a valid solution.

• CONST01: The resulting solution should cost less than 40€
• CONST02: The solution should be realized in less than 3 days
• CONST03: The solution should work with my existing roller shutters

I didn’t want to spend lots of money on a solution (CONST01). Furthermore, I got the idea for this project only 3 days before I left for my trip to Scotland, so I really wanted the project to be ready by then (CONST02).

The fact that the solution should work with my existing roller shutters (CONST03) seems like a no-brainer, but it isn’t. The roller shutters I have work with a remote control, but the shutters themselves don’t give any automatic feedback (now I’m up, now I’m down, …). Domotics solutions typically require feedback as well.

Quality attribute scenarios

Typically an IT architecture will be shaped more by the Quality Attribute scenarios (also known as non-functional requirements) than by the functional requirements.

• QAS01 (Testability): The solution should run stable for at least a full day before I go on leave
• QAS02 (Usability): It should be possible to modify the roller shutter timings in less than 10 minutes
• QAS03 (Availability): The solution should be stable enough so that it works in more than 99% of the cases
• QAS04 (Performance): The system should handle 2 requests per day: one in the morning and one in the evening
• QAS05 (Security): Other people should be prevented from controlling my roller shutters
• QAS06 (Interoperability): The system should work flawlessly together with my manual remote control (and I should be able to automatically fall back on the manual system when I disable the automatic system)
• QAS07 (Modifiability): It should be possible to extend the base system further in future. Some ideas:
  • Flexible management of the timings
  • Addition of my Velux roller shutters upstairs (now only the ones downstairs are considered)
  • Support for summer / winter time
  • Automatic determination of timings based on sunset / sundown
  • …

Architecture Decisions

The drivers from the previous step will now give shape to different architecture decisions.

Functionalities

There are 3 functionalities that should be handled in our system

• Manage schedule: This is the management of the timings when our roller shutters should go up and down
• Execute schedule: This is the part where actions are taken based on the schedule
• Send signal: In this functionality we’ll send the actual signal to the roller shutters

An architecture is often represented using the Archimate language. I used the Archi tool to make this overview.

Next to the 3 functionalities, you can also see 2 relations here:

• A flow relation: The schedule configuration will eventually be used for executing the schedule
• A trigger relation: During schedule execution, the roller shutter signal will be triggered

Please note that these are just functionalities. This diagram doesn’t tell anything yet about the (software or infrastructure) components in which these functionalities will be grouped. We’ll do that in a minute.

Software & Infrastructure components: Alternatives

I did some google research, and I came up with the following alternatives to implement these functionalities

1. Use the Somfy Tahoma smart home control
2. Use the Transceiver component of RFXcom in combination with the Raspberry Pi Domoticz software
3. Connect an extra remote to a Raspberry Pi, and control it via the Domoticz software
4. Connect an extra remote to a Raspberry Pi, and foresee custom (Python) programming to control it

Doubtless there are other alternatives as well, but remember that I have a timing constraint (CONST02).

Software & infrastructure components: Comparison & Decision

Rejection of alternative 1 (Somfy Tahoma)

• Its price of 300€ violates the cost constraint (CONST01)
• I have to order it online, so it will violate the timing constraint (CONST02), especially in combination with the testing quality attribute scenario (QAS01)
• I have some doubts about the modifiability (QAS07), but didn’t investigate this further
• The other quality attribute scenarios will be easily realized with this alternative

Rejection of alternative 2 (RFXcom transceiver)

• The price of 90€ (CONST01) and the delivery time (CONST02 + QAS01) are also an issue here
• I have less doubts about the modifiability (QAS07) of the Domoticz system, and I don’t see any problem for the other quality attributes as well

Preference of alternative 4 (custom programming) above alternative 3 (Domoticz software)

• In both alternatives, I could reuse a spare remote and an unused Raspberry Pi. So the cost constraint (CONST01) is not an issue at all
• I judged it would be easier to realize the timing constraint (CONST02) together with the testability (QAS01) with custom programming (alt4) as compared to the Domoticz software (alt3). I’m not familiar with the Domoticz software, and I found a couple of coding examples online for custom programming that didn’t seem too difficult
• The other quality attribute scenarios didn’t seem like a problem to me

So now we’ve made an architectural decision about the component that will realize our functionalities

Manage the schedule

Typically you would foresee a user interface to modify the timings, and a database to store them. The next functionality (Execute Schedule) will then read the database to know the timings.

However, QAS02 (Usability) says that it should be possible to modify the roller shutter timings in less than 10 minutes, which is not strict at all. And given the fact that there’s a timing constraint (CONST02), we can go for an even easier solution here.

I decided to hardcode the timings in the code itself. So if I want to change the timings, I have to log on to the Raspberry Pi, and edit the source code with the Nano editor. Not an elegant solution, but it matches with the constraints and quality attribute scenarios.

Security

In order to realize the security quality attribute scenario (QAS05 (Security): Other people should be prevented from controlling my roller shutters), it is sufficient for me to change my default Raspberry Pi password.

Fallback plan

There’s also the “fallback plan” quality attribute scenario: QAS06 (Interoperability): The system should work flawlessly together with my manual remote control (and I should be able to automatically fall back on the manual system when I disable the automatic system)

That’s automatically realized by unplugging the Raspberry Pi.

Architecture

Now it’s time to represent the resulting architecture in a diagram. This can either be done by a free-format overview, or by using a more formal way. The diagram itself will never explain the full story, so it’s always useful to foresee some extra clarification.

Free-format overview

A Raspberry Pi connected to a Somfy remote will control the roller shutters, using some Python scripts.

Formal overview

The formal overview is again made using the archimate language.

You can already see a difference between the blue part (the application part) and the green part (the infrastructure part).

There’s one application component named ShutterScheduler.py, which will be written in the Python programming language. A component is a real software component that will be created by a developer.

This component will handle our 3 functionalities Manage Schedule, Execute Schedule and Send Signal.

As you can see, the ShutterScheduler.py component uses the Python hosting infrastructure service (the arrow means “used by”). This service is offered by our Raspberry Pi infrastructure node (actually by the operating system Raspbian, but I didn’t model this explicitely for simplicity).

The Manage Schedule functionality will use the Nano editor, for the manual management of our timings.

And the Send Signal functionality will use the Control I/O pins infrastructure service to control the GPIO pins on the Raspberry Pi. And by controlling these GPIO pins, we’ll trigger the Somfy Remote (modelled as an infrastructure node).

And finally we have the purple block, which is a requirement to change the Raspberry Pi’s default password for security reasons.

Comparison

Both the free-format drawing and the formal one represent the same setup. But you can put a lot more information in the formal representation.

It’s important to note that you certainly need extra documentation as well, and that there are multiple ways to represent the same setup.

I prefer the formal representation when talking to developers, but often the free-format way is sufficient when discussing some architecture properties with your business users.

Conclusion

This may have been an simple scenario, but you can clearly see how the different architectural drivers have led to different architectural decisions, and how the resulting architecture can be represented in both a formal and free-format way.

And it’s also important to notice the difference between architecture and design: I didn’t say anything specifically about how ShutterScheduler.py should be coded. For example: I used the schedule library or the RPi.GPIO library, but you can’t see that in the architecture.

The architecture typically handles non-local changes (covering multiple components), while the design is often restricted to a single component.

References

The architecture method that’s used here (attribute driven design or ADD) is explained in detail in Software Architecture in Practice (3rd Edition).

And the Archimate language that I’ve used for the diagrams is described in Mastering Archimate.