It’s time to work these software architectures to the bone. You have spent enough markers on whiteboard sketches, and have considered many substantiated opinions from your developers regarding the future application. But there is still that tiny part that has yet to be convinced that what you’ve selected is the best option. No matter how objective and cold-hearted gazes we throw, the opportunity cost is always there to bite off – unless we make the “right” decision.
As it stands, this article is a closing note to our delve in Software Architecture. It has been some time since our blog articles have etched their name into your history tab, so we will take this opportunity to freshen your memory.
We have talked extensively about how programming & markup languages shape the world of software today. While that side is preoccupied with creating blocks of code, Software Architecture (further as SA) is about getting a bird-eye view on the DevOps, their bottomless cup of coffee, and strained eyes from fixing one bug and three more popping up. You see, developers sometimes get artistic influences, just like a writer, and wander off in certain implementations that could be hard to comprehend for other members of the team. Making sure the blocks are properly placed on one another, whilst paying attention to programming wanderers, is SA on the surface.
Placing blocks in certain ways can achieve different results. As technology saw its course of evolution, many patterns were tried and tested in various tasks. Some were better suited than others, but the core idea remained. Choosing a software architecture is playing a trade-off game. The ideal situation would be a zero-sum game, however, real-life situations don’t have all the future information packed in a codex. Which is why a crucial point is thoroughly understanding what the client needs and how best to support his idea.
How to blueprint software architectures
Multiple tried and tested patterns have been squeezed to their last drop by businesses and researchers alike. Their results have long been posted on forums, touched upon during corporate talks, either shared as part of content marketing strategies. Surely it is wise to make use of their arduous process and not reinvent the wheel. Following a certain style blindly can cause issues down the line.
Some questions must be answered before proceeding on with a project. Now, I’ll share the approach I overheard from many EBS Integrator developers. This will allow you to pinpoint the exact measures you need to consider when solving a problem for a client. Scope orientation will come after you sit down and write answers. You can always throw some boons and die to select a random pattern – just an afterthought, but not lucrative:
Define the business problem
What are we solving? What product are we building and why? How can we measure certain characteristics: success, failure.
Ask others how they dealt/ would deal with such circumstances. Get the StackOverflow slackers together and work out complete or partial solutions. Work your way from the top touching general issues, as compared to looking for the nitty-gritty.
You need to transfer the scribbled solutions into actionable blocks adding the necessary details. At this point, explanations should be lucent so everyone is on board. If uncertainties pile up, it means a further review is required.
Passing the whiteboard around is not lucrative so you have to migrate your blocks to a virtual template. Maybe add-up a note or two, align your sketches with business requirements and outline purpose. If you’re crammed in time, multiple tools allow you to jot diagrams, so at least make use of those. Remember: for some, diagrams without proper documentation, notes or an outlook on how your sketch reaches business objectives, are just a set of scribbles on the wall.
Process tradeoffs and alternatives
No best pattern will magically solve your issues and bring about a perfect development cycle. A good approach means scrutiny in regards to what benefits are traded. You can’t single out a pattern and say it’s inherently bad. Some patterns offer less in certain programmatic contexts as such other options seem more appealing. Carry a balance around – in your mind – weighing the pros and cons of certain ideas.
Asking a tech unsavvy client what he thinks of your decision will not amount to much insight. However, the engineers of your company could find some peculiarities, perhaps, important enough to net another review.
The approach to selecting the Software Architecture is not set in stone. It wise to spend time on the matter, but delving on it too much can prove counterproductive.
Choosing your Software Architecture Pattern
Not a proprietary technique, however, courtesy demands we share resources to drive competitiveness. The “correct”’ architecture style can be better understood if we screen it against somewhat objective factors. Placing a score on Quality Attributes is a good start for beginning a multi-criteria decision-making problem. You will find different authoritative experts articulate distinct Quality Attributes which only adds to the difficulty of choosing the one. However, consider the amalgam below a trustworthy guideline to discuss on:
|Implementation attributes||Ease of Maintenance||The extent of convenience when it comes to modifying and extending a system.|
|Ease of testing||The degree to which the system allows for running test cases. Testing often requires deep documentation and insight into the underlying system design.|
|Portability||Independence in regards to other software and hardware platforms.|
|Flexibility||The degree to which a system can be “bent” to suit a certain environment which was not initially planned.|
|Reusability||Reusability implies the capability of components to be used in entirely different applications or scenarios. Reusability counteracts redundancy and directly impacts the total code amount.|
|Simplicity||An attribute which describes how easy is it to maintain or add functionality to a system.|
|Runtime attributes||Availability||Availability defines the period for which the system was functional. For the sake of clarity, exact timings are used as an etalon. It is inversely proportional to downtime due to sundry internal and external issues.|
|Security||The ability to withstand malicious attacks no matter their point of origin and category.|
|Performance||Further explained by additional efficiency criteria such as response time, throughput, and resource utilization which can be used as benchmarks to test this quality attribute.|
|Concurrency||The capability to execute several computations in parallel. It also factors in the possibility of such actions interacting cross-core and cross-thread. Concurrency can be run in multiple threads of a core, multiple cores of a chip, or on physically separated processors.|
|Reliability||Reliability ascertains various failure parameters such as frequency, Time-toFailure, ability to recover and self-recover, failure predictability.|
|Scalability||System’s adaptability to user requests variability.|
|Business attributes||Cost||The total cost of building, maintaining, and operating the system.|
|Lifetime||The time before the product is retired.|
|User attributes||Usability||The level of satisfaction inferred from users interacting with the system. UI, UX, proper documentation, and technical support fall under this category.|
|System attributes||Ease of Support||Reflects the degree of technical support capability to perform various tasks on the system ranging from installing and configuring to identifying faults and debugging. Initial investments in supportability lower the overall maintenance costs down the line due to increased operational power of support personnel.|
How software architecture patterns fit various scopes
Like snowflakes, no piece of software is alike. Some enrich your pastime, aid your shopping, support your activities, while others can supersede entire factory or office operations. As per our meandering experience, scopes can be divided into 5ish industry non-related groups: Minimum Viable Products (further as MVPs), Evolutive MVPs, Data-Centric Solutions, Business Process Management (further as BPM) engines and High-Availability or High-Load services. With this in mind, let’s mix and match scopes and patterns.
A tiny bit of background
A Minimum Viable Product, or an MVP, is the concept of delivering the husk of a prominent idea with just enough features to attract early-adopters: customers, influencers, investors. It is also a testing ground that offers sufficient insight into the probability of a potential service being incorporated into a giant market. MVPs facilitate an agile development environment focusing on quickly implementing certain ideas fed into the feedback loop.
Eric Ries, the inventor of the MVP concept, describes MVP as a product that enables teams to harvest the maximum amount of validated information about customers with the least amount of effort (in software resources would be a better term). In a nutshell, it allows businesses to dip their toes in water and test if it’s warm or not. We won’t go into rules or reasons for building an MVP here, but check those enclosed links for the full show.
Proofs of concept or Demo MVPs
As mentioned before: we can identify two subtypes of MVP: demo and evolutive. A demo MVP is pretty much the first iteration aimed at illustrating an idea and giving the audience something interactive they can poke at.
Therefore, speed is key in such areas. Apart from the restricted allotted time, there is not much space to do other than get right into writing the damn code. Consequently, your developers need something actionable, easy-to-develop, supporting concurrent development, minimal testing. Your team can add complex functionality later, but impressing potential investors is a different story.
Introducing the shiny MVC(Model-View-Controller). It is a universal concept unrestricted by applications or software in any programming language. The core idea of MVC is:
- The Controller – The controller is akin to a traffic cop. It handles incoming HTTP requests and directs traffic to where it should go, identifying which view needs to load up.
- The View – The view is a blanket term for all elements constituting the user interface. Button, forms, fields.
- The Model – The model represents all the data retrieved from a database.
Two of MVC’s advantages make it a perfect candidate for your MVP demo:
Fast development process – aside from your developers’ deft hands, MVC supports rapid and parallel development. You can assign three developers to the respective component and you would have a three-fold developing speed.
Ability to provide multiple views – This advantage is more of a bonus but can work in your favour when picking at the interest of potential investors.
The MVC architecture allows for multiple views of a model. You get additional devices that can view your application while maintaining code duplication to a minimum since data and business logic are separated from the display.
On the other side of MVP rests the following iterations after the initial display. Your idea will append many functionalities and will walk the path of evolution, hence, evolutive MVP. The first MVC usages involved programming UIs, but that doesn’t mean that it wouldn’t be able to handle 50 million users. Of course, some hard decision making will have to occur regarding the server resources required. However, as a general idea sticking to MVC will not hurt unless your application has some peculiarities that would require qualities found in other architectures. While this is true for most of the cases, the more you delve into iterations, the closer you’re getting to a breaking point, where an MVC infrastructure won’t do.
Moving away from MVPs
As mentioned, MVC has its’ limits especially when horizontal scaling is involved. Then again, if anyone gets to this point, chances are there are more than enough resources to re-invent an MVP at a larger scale and chose another SA pattern.
Introducing the Service as a Service night or simply put SaaS. These applications are quite the trend in the digital world. While MVPs focus on building a quick foundation to leverage feedback and test ideas, SaaS is in the enterprise peaks. Consequently, there have been well-established pain points noted across the application’s lifecycle. That involves how to better optimize the efficiency and security of a system directed to convergency. A very thin line can be used to delimit 3 business scopes within SaaS infrastructure:
That thin line does data-centric applications no good to this particular scope. It is a blanket term for software architectures in which databases play a crucial role. While this approach is meant to put an additional highlight on the importance of databases, it goes without saying that in every modern application it is important to have one. Several tech-heavy characteristics can be employed to achieve the name “data-centric”. We have planned an entire BASICs series dedicated to these apps, hence the laconic entry. If I were, to put it bluntly, it would be like this: “A data-centric enterprise is one where all application functionality is based on a single, simple, extensible data model.”
One way to leverage the intense flow of data-centric applications is by applying the Microservices pattern. We have provided an in-depth explanation on Microservices and FaaS combo, so if you’re interested in having a peek at how it would benefit your business consider visiting it out. Enterprise applications can become quite overbearing, so many big businesses opted out of monolithic architectures in favour of more modular and decoupled systems. A first-hand example would be the infrastructure of Google as the most performing search engine. There are no spilt beans that data is the main focus and several papers have noted its efficiency. Needless to say, there are quite the techniques employed and these are the results of years of experience.
Business Process Management (BPM)
These apps relate to the practice of aligning goals and processes as businesses evolve. It helps organizations define minutiose tasks, mapping them to processes and working on streamlining or improving them so greater efficiency is realized. It is obvious that various sets of data are required to power such an application and you could make the mistake of misinterpreting BPMs as data-centric and thus opt for a microservices approach. However, Event-driven would be more suitable here due to the importance of measuring metrics, illustrating graphs and “actively listening” to the data pipeline. Cost-saving added efficiencies and increased value to businesses can only be achieved if certain patterns are recognized.
High-Load / High Availability Systems
On paper, applications promise to be obedient, but in the real world there can be situations when certain events – a sudden spike in traffic, too hot in the server room, power outages, system unresponsiveness – can cripple your application irrespective of whether they are hosted on your enterprise local servers or somewhere in the magical cloud. Situations like this are unavoidable. However, rather than estimating millions of losses in revenue it would be better to start investing in measures to allow for a High-Load / High Availability Application.
High Availability emphasizes a special configuration that enables a system to uphold desirable operational performance in the face of setbacks. There are no fixed rules and it’s up to the owner’s discretion of implementing said practices. Is there a special architecture that achieves this? Yes, it’s called High Availability software architecture which constitutes several best practices: Data Backups, Recovery and Replication, Clustering, Network Load Balancing, Failover Solutions, Geographic redundancy.
Leaving hardware behind, you might wonder wich SA pattern might fit these applications best? You might consider combining several patterns, however, this might end-up in a maintenance disaster that will require a steep recovery price. For this scope, the best-fit might a Space-Based Architecture (SBA) pattern.
The main advantage of this pattern lays within its design. Since this pattern splits processing and storage across multiple VMs, distributes datasets across various nodes, resembles more of a “cloud infrastructure” than a SA pattern, and stores information in RAM it ticks most checkboxes in the High-Load requirement sheet.
All in all
Our journey through the blazing sky observing the countless DevOps drinking their coffee and witnessing a bunch of error lines ends here. We have scooped the software architecture side enough to give you enough substantiated knowledge to be better prepared for tech-laden meetings. Assuming you have followed every article, it wouldn’t be surprising for you to be able to offer meaningful insight on how other applications work underneath. Moreover, make sure to recommend other business ventures to not overstay their thoughts in the realm of selecting the chosen software architecture as it’s a brittle plan.