There’s a quote by the playwright Oscar Wilde that goes something like:
The only thing worse than being talked about is not being talked about.
Believe it or not, this is also true of software architecture. Engineers love to crank out code. Design and architecture of a system often plays second fiddle, if it plays at all.
Why Care About Software Architecture?
The Agile Manifesto starts with, and is fairly well summarized with the following sentence:
We are uncovering better ways of developing software by doing it and helping others do it.
This is astute: who could argue with that? Agile has put the focus of the software development process squarely on the sole process of writing and delivering code. This is a pure statement of the importance of learning by doing. The manifesto proceeds by describing four priority statements and 12 principles. One of the principles, Number 11, states that the best architectures are emergent purely from code that is being developed feature by feature, rather than being designed upfront. At first glance, Agile does not play well with design and architectural approaches.
Over the past two decades, Agile and the manifesto have strongly and deeply influenced the software development process at almost all levels and organizations. Many groups have shown huge gains and happy customers from Agile approaches; we’re not here to denigrate that. And no one in their right mind today would promote the BDUF (big design up front) model as the be-all and end-all of creating a modern, high-performance, highly available and fault tolerant system. There are just too many unknowns at the beginning. It’s why Agile works so well!
We here at Split are in favor of “just enough” architecture. It’s important to take your medicine of system design. The architecture of a system exists even if it’s not documented. Without a documented architecture, you can lie victim to the bus factor. In other words, it creates problems of unshared knowledge and unknown points of failure. If someone critical were to leave the project or the company, how could you maintain continuity without their knowledge? Moreover, you also want to make sure the system you are going to build is fit for purpose—that it meets the primary goals of what you are setting out to achieve by building it in the first place. Even if the first delivery of code or first few deliveries of code don’t satisfy all requirements—and they most certainly won’t—you want to track toward a design that does.
Before we dive any further, though, let’s define what software architecture actually is. According to Carnegie Mellon University’s Software Engineering Institute (SEI):
The software architecture of a system represents the design decisions related to overall system structure and behavior. Architecture helps stakeholders understand and analyze how the system will achieve essential qualities such as modifiability, availability, and security.
What Split Offers
Many different ways to implement and deploy! Each company and organization using Split are almost certain to vary. But there are shared commonalities. Some companies use microservices, some are serverless, some use AWS, some use Google Cloud. Others are intensively REST API-based internal architectures, others are monoliths. Some may have a CDP for customer data tracking and utilize many other off-the-shelf components, while others have built their own systems and have that as a core part of their culture.
Split offers a wealth of implementation options and resources to help guide you in making the right architectural decisions for what you are setting out to accomplish. Split Help Center’s Integration and Automation, SDK documentation, and Optional Infrastructure documentation are great places to get started. Some of our blog posts and help center articles also include common architectural patterns, such as a serverless implementation on AWS Lambda.
That’s a lot to take under one’s belt as it is. It can seem like quite a daunting task to determine then how to actually put that all together in a way that meets the goals of the stakeholders of a software development project. The good news is that just getting started is very easy. The documentation for Split’s SDKs sample code and tutorials to get up and running very quickly. In fact, we have many examples on our blog of getting up and running in as little as 10 minutes—such as this example with React or this example with Python.
It’s great to get Split running in your environment quickly, but in larger enterprise-style organizations, you may need to implement Split for multiple teams or across a myriad of different applications and services. How do you make sure what you’re developing is going to handle the traffic volumes you need? How do you make sure it’s going to capture events for experimentation? Or make onboarding new teams a snap? Where do you even start with this? How do you take your implementation of Split to the next level?
How Do You Do It?
One approach that can allow you to start putting one foot in front of the other is the Attribute Driven Design (ADD) approach. Attribute Driven Design is an iterative architecture design approach that was developed at SEI in order to create a repeatable process to allow software architects to design fit-for-purpose software systems successfully. Its website contains a wealth of videos and documentation on this topic, and there also is an IEEE paper that goes in-depth for each step.
According to ADD, architectural diagrams are split into three different styles. Module styles are primarily made of (you guessed it) modules. Modules are implementation units that provide a set of responsibilities. A module style helps readers understand is-a, is-part-of and depends-on relationships. Next, Component and Connector styles are what people most commonly think of when imagining architecture documentation. These map components (such as services, processes, threads) to other components with connectors—such as pipes, queues and other methods of invocation. The third style is what is called allocation style. Allocation style diagrams describe where things are actually going to “run,” so to speak: the allocation of software units to the elements of the running environment where it will execute.
Summarized succinctly, the process of ADD is:
- Gather a purpose for what your system should do
- Includes functional requirements, concerns constraints
- Includes quality attributes — often called non-functional requirements
- Review the gathered information
- Determine a goal of the iteration
- Select drivers (from Step One) to focus on
- Choose one or more elements of the system to define
- Instantiate elements, allocate responsibilities, define interfaces
- This is where you actually decompose the requirements into architecture artifacts
- Sketch views and record design decisions
- Analyze the design and review the iteration goals: How well have you achieved your requirements so far?
- Go back to Step 3 to do an additional iteration if desired
The iterative approach allows you to finish when you’ve gotten enough architecture to start development or have met all of the drivers you’ve identified in Step One. It also lets you pick up and start again when requirements change or get added, or need further refinement, which a BDUF style of architecture development simply would not let you do. With this “just enough” approach, you can be as Sgile as you need to be.
A well-designed software architecture doesn’t get in the way of starting development. It’s not the case where you would want to spend weeks and weeks in the weeds documenting the architecture before you write a line of code: You only need “just enough.” It enables ease of maintenance and adding new functionality.
An architecture process should focus on the most critically important properties of the system: quality attributes such as scalability, maintainability, performance, and deployability. These need to be built into the design at the beginning rather than discovered and bolted on down the line. This leads to savings in effort and cost, reducing unnecessary rework and distributing knowledge of a system’s components and core capabilities.
Composing and integrating Split into all of the places and in all of the ways necessary to create a world-class feature flagging and experimentation capability in the enterprise is an exciting opportunity.
Split is here to help!
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.
Switch It On With Split
The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Switch on a free account today or schedule a demo to learn more.