At Aeterna, we aim to inform our clients about the critical design processes our experienced software architect uses to create great software. Reflect on your past projects—did they have a solid design?
Could it have been better? Was there even a design in place?
Consider these questions:
How easy was it to make changes to your code?
Did small adjustments cause ripple effects elsewhere?
Was your code difficult to reuse?
Did maintenance become a headache after a release?
If you answered "yes" to any of these, you likely need a better design. Good software design isn't just about code; it’s about clearly communicating ideas with developers, teams, and clients. A well-thought-out architecture makes implementation smoother, reduces the need for major changes later, and saves you from future headaches.
At Aeterna, we ensure your software design is flexible, reusable, and maintainable.
What is Software Design and architecture at Aeterna
What exactly is software design and architecture, and how do they enhance the quality of software products? Consider this scenario: You join an ongoing project that has been in development for some time. When you look at the code, you are immediately overwhelmed. It's difficult to understand the purpose of various components, things are poorly organised, and there's no design documentation. You’re unsure where to even begin. These are clear indicators that the project wasn't properly designed from the start.
Now imagine you’re working on a personal development project. Initially, you weren't sure about all the features, so you dove straight into coding. Since you were the only one working on it, the disorganised code didn't seem like a big issue, after all you knew how everything worked. But, when you later tried to implement a great new feature, it ended up breaking other parts of the program. In hindsight, you should have designed it properly from the beginning
Scenarios like these are common in the software industry, and they highlight the importance of good software design and architecture.
What is The difference between Software Design and architecture at Aeterna
What is the difference between software design and software architecture? These are questions we'll explore in more detail throughout this blog. However, let's take a quick look now. Like many roles in the software industry, the responsibilities of a software designer or software architect can vary significantly from one project to another. Generally factors such as company size, project scope, the experience of the development team, organisational structure, and the company's age can all influence how these roles are defined.
In some companies, there may be distinct positions for software designers or architects, while in others, these responsibilities may fall to members of the development team. Typically, a software designer is responsible for outlining a solution to a specific problem by focusing on the details of individual components and their roles. On the other hand, a software architect looks at the system, selecting appropriate frameworks, data storage solutions, and determining how different components will interact with each other.
This brings us to the key difference: software design focuses on the lower-level details of a system, while software architecture deals with the higher-level, big-picture aspects. To use a building analogy, the architect handles the major structures and services, while the interior designer works on the smaller, more detailed spaces.
Great software designers and architects are both detail-oriented and forward-thinking. They must be able to view the product from both the high and low levels, be creative problem solvers, and communicate effectively with product managers and development teams to deliver quality solutions.
How Aeterna does client orientated architecture right
At Aeterna, we believe architecture starts with understanding the client's business problem. Our primary task is to grasp what the client needs, as this foundational insight guides everything else. Once we fully understand the problem, we can draw on our previous experiences to identify successful solutions, helping us envision the overall architecture of your project.
At Aeterna, we see architecture as the study of components (the “boxes”) and their relationships (the “lines”). This foundational understanding is crucial for creating stable, long-lasting systems. While anyone can build a system that lasts a short time, developing an architecture that supports sustained contributions over years requires careful thought.
Our focus is on the long game, ensuring you avoid suboptimal short-term decisions. The importance of architecture is not taken lightly at Aeterna; getting it wrong can jeopardise your project’s long-term success. By prioritising thoughtful design, we help set the stage for enduring outcomes.
One of the key challenges in software architecture is the ongoing trade-off between speed and quality. Customers often want their software delivered as quickly as possible, pushing for immediate results. In contrast, engineering teams aim to build robust, well-designed systems that are thoroughly implemented.
This tension between rapid delivery and careful design creates a dynamic where both sides must find a balance. While the urgency for speed can lead to quick wins, it can also result in rushed decisions that compromise quality. Conversely, a focus on building a perfect system can delay delivery, missing critical market opportunities.
We believe that navigating this trade-off is essential to producing high-quality software. It’s through this process of balancing speed and quality that teams can arrive at well-thought-out designs and effective solutions. Embracing this challenge fosters innovation and leads to better outcomes in the long run. Ultimately, it’s a continuous process where both perspectives are valued and integrated.
At Aeterna, our primary focus is to partner with clients in uncovering their true objectives. Many clients have a general sense of improvement but may not yet have clarity on specific needs. One of our key roles is to facilitate that understanding. Our software architect acts as a bridge between the client, product managers, and engineering teams, ensuring that we translate client needs into precise technical requirements. This collaborative approach helps us align solutions with both customer expectations and best practices.”
At Aeterna, we place a strong emphasis on understanding and serving our clients while staying within their budget constraints. For smaller projects involving straightforward functionalities, our process is highly collaborative. We often sit down with an engineer, using a whiteboard to brainstorm and sketch out potential solutions. This hands-on approach allows us to quickly develop a design that meets the client's immediate needs and fosters a creative, agile environment.
In contrast, larger initiatives require a more structured approach. For these complex projects, we create comprehensive design specification documents. These documents explore a wide range of use cases and flow variations, ensuring we capture all critical functional and nonfunctional requirements, such as system stability, maintainability, and performance metrics. This thorough exploration helps us mitigate risks and align our solutions with the client's long-term goals.
To effectively communicate our software architecture, we rely heavily on written documentation. This includes wikis for collaborative updates, white papers that provide in-depth analyses of our design decisions, and detailed engineering design schematics. We utilise class diagrams to illustrate relationships within the system and high-level architecture diagrams to offer a clear overview of the entire structure when necessary.
By tailoring our approach to the scale and complexity of each project, we ensure that we not only meet our clients’ requirements but also deliver solutions that are well thought out and aligned with best practices.
At Aeterna, we believe that simplicity is the key to success. Our engineering maxim is rooted in two essential principles. First, when our solutions are simple yet effective, the likelihood of achieving the desired outcome significantly increases. Second, simplicity enhances communication. It’s crucial to convey architectural concepts clearly, as we won’t always be around to explain them. If our solutions are complicated, the cost of knowledge transfer rises, making it more difficult to explain and increasing the chances of misunderstandings.
Aeterna example object orientated software’s
Object-oriented Modelling is one of the methods we use at Aeterna for modelling software. This involves the practice of representing key concepts through objects in your software. Depending on the problem, many concepts, even instances of people, places or things become distinct objects in the software. Think in terms of objects. Objects are all around you. Look around, what do you see? I'm guessing you see a computer or a tablet. You may also see other physical objects like a table, a door or a coffee mug. Is there anyone else in the room? They are objects as well. The room itself is even an object. So why should you use objects to represent things in your code? It is a way of keeping your code organised, flexible and reusable. It keeps code organised by having related details and specific functions in distinct, easy to find places. This creates flexibility because you can easily change details in a modular way without affecting the rest of the code. You can also reuse code and keep your program simple.
At Aeterna, we believe that software development is a collaborative journey that transforms problems into effective solutions. Our iterative approach ensures that we are with you every step of the way, guiding you from the initial formation of requirements to the final design.
We recognize that jumping straight into coding can be tempting, but this often leads to misunderstandings and project setbacks. Research from The Standish Group highlights that many project failures stem from issues related to requirements and design. For example, about 13% of respondents identified incomplete requirements as a major obstacle.
That’s why we take the time to work closely with you to clarify your needs and create a solid design. Together, we’ll explore and refine requirements, ensuring that every detail is addressed before moving on to implementation. While perfection may not be achievable, our commitment to thorough planning significantly enhances the likelihood of delivering effective software.
By partnering with you throughout this process, we can build a comprehensive solution that not only meets your expectations but also sets the stage for successful outcomes.
At Aeterna, we continuously engage with our clients to explore their vision by asking insightful questions about issues they may not have considered. In addition to identifying specific needs, we also discuss the potential trade-offs involved in forming their solution.
By developing a clear understanding of our objectives and accounting for all nuances, we can swiftly move to create conceptual design mock-ups. These eventually evolve into detailed technical design diagrams, which we share with our clients to ensure alignment and transparency throughout the process.
For example building a house
Imagine you're hired to design a house. Before you begin construction, it's crucial to understand the homeowner's needs—this process is known as **eliciting requirements**. The homeowner specifies that they want a single-story house with a gym, a bathroom, three bedrooms, and a living room. However, eliciting requirements isn't just about listening to what the client explicitly states; it's also about asking insightful questions to uncover missing details.
For instance, did you notice there's no mention of a kitchen? That's a logical follow-up question: "Will you need a kitchen?" You might also ask, "Should all the rooms be the same size? If not, which ones should be larger or smaller? How large should the house be overall?" Further questions could explore external factors, such as local building regulations or whether the house should be oriented to maximise solar energy or capture scenic views. You could also inquire about room placement: "Which rooms should be located near each other, and which should be farther apart?"
The key to effective requirement elicitation lies in asking probing follow-up questions that reveal more than the initial information provided. Once these questions are answered, you can develop a clear set of requirements to guide your design process.
The next step is designing a solution based on these requirements, which involves creating both a conceptual design and a technical design. These result in two different types of outputs: conceptual mock-ups for the overall idea, and technical diagrams for the detailed implementation.
At Aeterna, our conceptual mockups represent our initial thoughts on how to satisfy the requirements of a project. Using a house design as an analogy, we begin by identifying major components and their connections, deferring technical details for later.
Consider the key elements of your house project: the lot, the house itself, and individual rooms like the kitchen, gym, bathroom, bedrooms, and living room. Each of these components is interconnected. For instance, if the living room is accessible from the kitchen, there is a direct connection between the two spaces.
Additionally, each component has a specific responsibility. The gym provides space and equipment for fitness activities, while the kitchen is responsible for storing kitchenware, appliances, and food, as well as supplying power and water for meal preparation. The house, as the main component, has the overarching responsibility of supplying power, water, and structural support for all the interconnected components.
By sharing these conceptual mockups with our clients, we ensure that we align our vision with theirs, paving the way for a successful project.
Notice that we aren’t discussing the specifics of wiring and plumbing yet. These technical details are best addressed after the conceptual design is fully developed. For instance, determining the size of the electrical panel will require knowing the power needs of each room. It’s advisable to complete the conceptual design before diving into the technical details, as a clearer conceptual plan will lead to more effective technical designs.
For example building a house – technical design
It’s now time to define the technical details of the solution. From the conceptual design, you have identified the major components, their connections, and their associated responsibilities. The purpose of technical design is to describe how these responsibilities will be fulfilled. This involves specifying the technical details for each component by breaking them down into smaller, more specific parts. For example, the gym component might be broken down further to include the floor, which is responsible for supporting heavy loads, particularly since the homeowner is training as an Olympic lifter. By continuing to break components into more detailed parts, each with distinct responsibilities, you reach a level where you can create a detailed design for specific elements, such as how to reinforce the gym floor.
Technical diagrams are used to address such specific issues. Challenges or compromises may arise during this process. For instance, reinforcing the gym floor might require adding columns or beams in the basement below, which could conflict with the homeowner's desire for an open basement with good headroom. In cases like these, compromises must be worked out, requiring constant communication and feedback to ensure the solution is acceptable.
If the components, connections, or responsibilities from your conceptual design proved unworkable or fail to meet requirements in the technical design phase, you may need to revisit and revise the conceptual design. As you work toward a feasible design, it’s crucial to regularly check with the client to ensure the conceptual plans align with their vision. In architectural projects, these checks are vital because it’s far easier to make adjustments on paper than to demolish walls later. Ultimately, the technical diagrams serve as the foundation for building the solution as envisaged.
Categories of Objects in Design at Aeterna
By organising your software into entity, boundary, and control objects, we create a more flexible, reusable, and maintainable codebase.
Entity objects represent real-world items in the problem space, such as a chair, building, or customer. These objects can modify their own attributes according to specific rules, making them essential for modelling the domain accurately. When identifying objects in your software, you'll typically start with entity objects, as they form the foundation of your application.
Boundary objects serve as intermediaries between systems, facilitating interactions with external software, the internet, or user interfaces. These objects manage input and output across system boundaries, ensuring that data flows smoothly and securely between different components.
Control objects coordinate the interactions between other objects, helping manage their activities and maintain loose coupling. For example, a Mediator object ensures that various entities communicate effectively without being tightly linked, promoting better organisation and flexibility.
By thoughtfully incorporating these object types into your software design, you not only improve maintainability and reusability but also enhance the overall robustness of your application.
Aeterna quality performance trade-offs
When designing software to meet requirements, together we face many important decisions, including trade-offs between different quality attributes like performance, convenience, and security. Consider designing a front door for a house: to enhance security, you might add locks. A single lock feels insufficient, so you keep adding more for extra protection. However, eventually, unlocking the door becomes inconvenient and time-consuming. Rather than simply adding more locks, you need a design that balances security with convenience and efficiency. Similarly, in our software designs, we find that it is crucial to consider how various qualities can conflict in different scenarios and find a suitable compromise. This balancing act is a key responsibility for Aeterna.
At Aeterna, we focus on balancing critical components like usability, performance, and scalability. However, we often face trade-offs between code quality, security, and time to market. Our role is to advocate for high code quality while navigating business constraints, not to rigidly adhere to standards at the expense of progress.
Clients want rapid releases, while engineers strive for perfection, aiming for 100% code coverage and extensive testing. We recognize that achieving these goals involves constant negotiation. Ultimately, our mission is to ensure a robust code base while effectively managing competing priorities.
And so, at Aeterna our analysis is relentlessly establishing what is the correct output. What are the non-negotiables? What must you do? And then, what can you negotiate on? And once we have established this, once we have those guardrails we can begin effective execution.
As your software design progresses and implementation begins, it’s essential to verify quality through reviews, tests, and user feedback. Meeting functional requirements alone isn’t enough; you must also balance qualities that matter to both users and developers. The way you structure your software affects its performance, reusability, and maintainability. Common trade-offs arise, such as sacrificing maintainability for high performance or reducing performance to boost security. Likewise, backward compatibility can negatively impact both performance and maintainability.
In software design, you often need to balance competing qualities. For instance, you might trade some performance for increased security or reduce backward compatibility for better performance. The final design must also reflect project constraints, ensuring a balance between quality attributes and available resources. By understanding these qualities as competing ideals, you can make informed decisions and trade-offs to achieve the best overall solution.
Conclusion
At Aeterna, we understand that effective software design and architecture are not merely technical tasks; they are critical components that shape the success and longevity of software products. Our approach emphasises a deep understanding of client needs, meticulous planning, and iterative refinement. By distinguishing between software design and architecture, we ensure that both high-level visions and granular details are addressed, creating a cohesive framework that facilitates collaboration among all stakeholders.
Navigating the trade-offs between speed and quality is essential, as we strive to deliver robust, maintainable solutions that meet market demands without sacrificing integrity. Our commitment to simplicity enhances communication and fosters knowledge transfer, enabling teams to adapt and evolve over time.
As we partner with clients through each phase of the development journey—from requirement elicitation to conceptual and technical design—our goal remains clear: to transform complex challenges into effective solutions. By prioritising thoughtful architecture and design, Aeterna not only helps clients achieve their immediate objectives but also lays the groundwork for enduring success in an ever-evolving technological landscape. In this way, we empower organisations to navigate their unique journeys, ensuring that their software stands the test of time.
