Image source: https://flic.kr/p/hqFAs2, Creative Commons License
Parti, the Big Idea
Architects call the central idea or concept of a building parti pris or just parti. This term comes from the French prendre parti meaning “to make a decision”. You can think of parti as the big idea behind an architectural design which is often “expressed by a diagram depicting the general floor plan organization […] and […] its experiential and aesthetic sensibility” (Quote from Frederick M.: 101 Things I Learned in Architecture School, MIT Press, 2007 – a recommendable book).
Parti Protects Your Software Architecture in Agile Projects
Particularly non-trivial agile projects require the existence of a parti, a big idea. I am not arguing for a waterfall-model with big design upfront. I am demanding an orientation point which helps to keep the architectural design of your software consistent while enhancing it in iterations using agile principles.
Examples for typical problems of agile teams without a parti are:
- Software architecture is not documented and not manageable
- Software architecture is unsuitable for maintenance and extensions
- Time and money are wasted because detailed design and implemented is started too early
- Estimations (time and budget) are wrong because the project scope is not fully understood
- Technical features of programming language, frameworks, hardware, etc. determine the architectural design
Our Own Parti
For our own software products time cockpit and Cockpit Framework (CoFX), we spent many months developing the initial software architecture parti when we started our company. We also documented and presented it in presentations, conference papers, magazine articles, videos, etc. Here are some examples of topics covered by our own parti:
- Key requirements of our products’ users and how we generally want to solve them
- Building blocks for SaaS (e.g. multi-tenancy, availability, scalability, security)
- Customization and extensibility concepts
- Platform strategy (e.g. cloud-platform, runtime, programming languages, libraries)
- Business model and how it translates into our software architecture
We created the following video in which we describe some aspects of our parti. It was filmed three years ago. Technical details have changed but the core pricinples are still very much valid because we aligned our detail decisions to it.
Do You Have a Parti for Your Software Architecture?
Over the years, our parti has been acting as a guidepost for many day-to-day design decisions and it still is. In our consulting work, we regularly visit software development companies for workshops, trainings, and code reviews. Most of them don’t have a parti at all. Some have, but it only exists in the mind of a single person. Only very few can answer questions like this:
- What are the foundational principles of the architectural design of your products?
- On a high-level, how do you think your software architecture will look like in three to five years?
- What are the core pillars in your architectural design that will most likely not change despite the rapidly changing environment in software development?
We are strong believers that a clear and documented parti is very important for the long-term success of software products. During the lifecycle of a software product, developers and architects have to make a huge number of decisions. The parti should be the golden thread running through all of them.
Pitfalls in Parti Development
You don’t create a parti for a non-trivial software products in just a few hours. This process is exhausting and time-consuming because requirements might be unknown, technical complications appear, you forget things, etc. Plan enough time for developing the parti. Starting detailed design or implementation without it is a waste of time and money.
The number of patterns, tools, libraries, best practices, great ideas, etc. is sheer endless. Beware of cramming all of them into your parti. Aim for a clean, consistent, and simple (not naïve) parti that fits your project’s needs. Save all the other great ideas for other projects in the future.
If you are struggling with the balance between complexity and simplicity, I recommend looking at John Maeda’s Laws of Simplicity. You might find some inspiration there.
Maintain Your Parti
When you managed to create and document/visualize your initial parti, your work isn’t done. Customers and stakeholders frequently change their mind. Probably you will try to stick to your parti as long as you can. You will add patches and small fixes to your architectural design. It is hard to recognize when a parti is no longer appropriate. In that case you have to abandon it, make major changes to it, or even create a new one.
Poor software architects stick to their parti even though small extensions, patches, and fixes that happen naturally over time in agile projects destroyed the integrity of the whole.
Frederick M.: 101 Things I Learned in Architecture School, MIT Press, 2007, Page 26
Role of the Software Architect
It is the job of the software architect in an agile project to recognize when the existing parti is no longer valid. Together with her team, she has to make larger changes or create an entirely new parti that incorporates all the knowledge gathered over time. The new parti will act as the guideline for future iterations.
Summary
- Take the time to develop a parti, a big idea, for your software's architectural design.
- Visualize your parti so you can share it with stakeholders, colleagues, employees, etc.
- Align your detailed design decisions with your parti to keep the integrity of your product.
- Be brave and accept when it is time to abandon your parti and create a new one.
- As a software architect, you are responsible for developing and maintaining the parti in your agile team.
Learn More
Dou you want to learn more about the concept of parti and how it relates to product design? The following video of a conference session of Luke Wroblewski (Product Director at Google, former Chief Design Architect (VP) at Yahoo!) could be of interest for you:
comments powered by