What is an utility tree and what is it’s purpose in case of Architecture tradeoff analysis method(ATAM)?

One of our teams is writing a service, that among other things, runs map/reduce jobs built as pig scripts with Java UDFs. The scripts accepts CSV files which have a text header followed by lines of data. It performs some grouping and then calls a UDF which essentially filter, enrich and transforms the data outputting another CSV with a new header followed by data – something like the following:

1
2
3
4

input = load '/data/INPUT2.dat' using PigStorage(',')...
grouped = GROUP input BY key;
results = FOREACH grouped GENERATE  evaluateUDF(input) as output;
STORE output...

and all was well. The job spawns a few map tasks partitions, groups the data and runs a single reduce where the actual evaluation happens.

Then someone wanted it to run faster – We can do that by adding reducers we can do that by adding PARALLEL X to the group statement where X is the number of reducers we want. And then the trouble began. Everything worked well for up to 5 reducers – go any higher and few results were lost. The script is pretty basic (the actual script looks a little different but that’s basically it) the UDF is not earth shattering yet still sometimes results are lost.

Even though I am very busy (well, not really, but you know, some members of my team might be reading this…) this was so annoying I just had to understand what happen so I took it upon myself to debug this. The main problem was I couldn’t write a unit test to duplicate the behavior  - it only occurred when running on the large file…

First thing I noticed is that we had duplicate results in the output, I removed those and saw that actually we’re only losing one result (again, only with 5 or more reducers). I diffed the  correct output with faulted one and I even had the problematic key.

I told myself something must be wrong with the partitioner  - The default partitioner that pig (and hadoop in general) uses is fairly simple it takes the hash code of the key, ands it with max int (so we get a positive number) and divides that by the number of partitions:

1

 return (key.hashCode() & Integer.MAX_VALUE) % numPartitions;

I couldn’t really see what might be wring with this but still I wrote my own instead:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

 
public class Partition extends Partitioner {
    //@Override
    private final static Logger logger = LoggerFactory.getLogger(Partition.class);
    public int getPartition(PigNullableWritable key, Writable value, int numPartitions) {
        try {
            if(key.getValueAsPigType() instanceof String) {
                String skey=((String)key.getValueAsPigType()).replaceAll("\"","");
                Long ikey= Long.getLong(skey);
                return (int)((ikey& Long.MAX_VALUE) % numPartitions);
            }
            else {
                return (key.hashCode() & Integer.MAX_VALUE) % numPartitions;
            }
        }
        catch (Exception e ){
            return 0;
        }
    }
}

Problem solved – everything works.  I guess that damn Hadoop partitioner is all flawed – not! – So now I am even more annoyed because I really don’t understand what’s going on here. but at least now I control the partitioner so I added some logging. I saw that the problematic key goes to partition 0 – so I made everything go to partition 0 and everything worked. then it finally stuck me. I logged all the keys that go into partition 0 and saw that the problematic key is the first .   Duh!  I should have noticed that earlier. Here’s what the UDF code essentially looks like:

1
2
3
4
5
6
7
8
9
10

	public DataBag exec(Tuple input) throws IOException
	{
            if (session == null){
                 session = ....
                 return addHeadersNames();
            }
 
            return  eval(input);
 
	}

The Tuple is the input we get from the pig script into our UDF, what happens here is that we throw out the first input we get and just output the headers for our result file. As it happens when we have enough partitions a significant input (the missing result) is the first we get in the partition

The developer who wrote this assumed that the first input line the UDF would get would be the input header file. It is alright to discard it and output the new header file instead. However Hadoop doesn’t work like that when we have code that runs in a map/reduce it might be called in different circumstances that we originally assumed and we have to pay attention to that. For instance, another problem with the code above is that when run with multiple reducers you get multiple copies of the output header…

So there you have, the title says it all : develop map/reduce code with reduced assumptions

The current (and hopefully final) table of contents  is as follows:

• Part I – SOA Patterns
• Chapter 1 – Solving SOA pains with patterns – an introduction
• Chapter 2 – Basic structural patterns
• Chapter 3 – Performance, scalability and availability patterns
• Chapter 4 – Security and manageability patterns
• Chapter 5 – Message exchange patterns
• Chapter 6 – Service consumer interaction patterns
• Chapter 7 – Service integration patterns
• part II – SOA in the real world
• Chapter 8 – SOA anti-patterns
• Chapter 9 – Putting it all together – a case study
• Chapter 10 – SOA vs. the world – how SOA fits with other techs:  REST, Cloud and Big data

I suppose it would take some more time before the final version of the book will be available (it is getting there…) but I guess  this is also a good time to thank the thousands of you who bought this book  via early access even though it was far from finished.

1
2
3
4
5
6
7
8
9
10
11

@Path("/stat")
public class StatusResource {
    @GET
    @Produces(MediaType.TEXT_PLAIN)
      public String getStatus() {
        if (checkStatus())
            return "Ok";
         else
            return "Not so good";
    }
}

Then we tried to connect a silverlight client to this server (don’t ask me why).  The first hurdle was a security one. Silverlight doesn’t like to communicate with a server it didn’t launch from. To resolve that you need to add a ClientAccessPolicy.xml to the root of your domainto allow cross-domain access. Here’s a simple all-permissive version of it:

1
2
3
4
5
6
7
8
9
10
11

@Path("clientaccesspolicy.xml")
public class ClientAccessPolicyResource {
    @GET
    @Produces(MediaType.APPLICATION_XML)
    public String getStatus() {
        return "<?xml version=\"1.0\" encoding=\"utf-8\"?><access-policy><cross-domain-access><policy> <allow-from http-request-headers=\"*\"><domain uri=\"*\"/></allow-from> <grant-to> <resource path=\"/\" include-subpaths=\"true\"/>"+
     " </grant-to></policy><policy ><allow-from http-methods=\"*\"><domain uri=\"*\"/></allow-from><grant-to>"+
      "<resource path=\"/\" include-subpaths=\"true\"/> </grant-to></policy></cross-domain-access></access-policy>";
    }
 
}

By the way – since silverlight is entirely a client technology you can also serve it from the Java web server (as long as you emit the right mime-type ) in which case you don’t need the cross-domain policy mentioned above.

Another interesting phenomena we saw was that the client only got the response once. no matter how many times we polled the server. We ran fiddler and saw that no request are in fact going out to the server – it was the browser’s (IE8) cache that was holding us back. It took me some head scratching as to how to solve this – but the solution is pretty simple – return an ‘expires” http header from the server to make sure the browser will only cache the result for a limited time. To do that with jersey you need to return a Response object instead of the text (or JSON/HTML etc.)

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Path("stat")
public class StatusResource {
 
    @GET @Produces(MediaType.TEXT_PLAIN)
    public Response getStatus() {
 
        Response.ResponseBuilder response = Response.ok(checkStatus);
 
    Date expirationDate = new Date(System.currentTimeMillis() + maxCacheInterval);
    response.expires(expirationDate);
     return response.build();
    }
 
}

While I think Silverlight is a technology on its way out. It is still around. It is nice to know that with a couple of simple moves you can get it to play nice even with a Java backend

Illustration by arinas74

When we try to think about service consumers, the obvious candidates are, of course, other services. Nevertheless there are other software components that interact with services e.g. legacy systems,  Non-SOA external systems or reporting databases. The Composite Frontend pattern deals with yet another type of service consumer – the User interface.

First let just verify that User interfaces aren’t in fact services. One reason user interfaces are not services is that they converge several business areas e.g. if you want to enter an order you’d probably also want to lookup information about the customer, maybe you’d also want to browse the product catalog, look at open invoices etc. In addition to convergence, user interfaces deliver data rather than process it. User interfaces are data producers (actually there’s one exception to that – where the UI is the front of a “human service” see orchestrated choreography pattern (in chapter 7) for more details.

Ok, so UIs aren’t services, does it matter? Well, it does and the problem is not that UIs aren’t services per se. The main challenge caused by user interfaces comes from their main difference i.e. the aggregation or convergence of several services into a cohesive and useful UI.

6.1.1      The Problem

To better understand the challenges caused by user interface working with multiple services, let’s consider an example with just a single point of friction.

In a project I worked on we’ve designed the C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) system for an Unmanned Naval Patrol Vehicle (UNPV). One of the services in the system was dubbed “Common Operational Picture” or COP for short. The COP ‘s responsibility was to handle anything that is detected by sensors e.g. ships, planes, whatever (There’s technical jargon for all that like targets, detections, tracks etc. but that’s not important here). One of the main UI representations of the COP was a map ,such as the one in figure 6.4 below, which showed all the detections. Clicking on map icon, say a ship, presents some information the COP knows about it, such as id, nationality, course  etc.

 Figure 6.4 A simplified  illustration of a  front end for a “Common Operational Picture” service of a naval command and control system. We see a shore line and then using NATO symbology: 2 radars, a submarine and an a ship (the Unmanned Naval Patrol Vehicle)

The system had a few other services in addition to the COP, amongst them there was the “UNPV service”. The UNPV service was responsible for anything related to the UNPV itself for instance, setting it on a navigation course, turning it around, etc. The UNPV service had several UI screens to allow managing and monitoring these functions. Another responsibility of the UNPV service was to send its location to the COP (locations are the COP’s responsibility, remember?) so back in the UI, one of the icons of the map is that of the UNPV.

What happens when a user clicks on the UNPV icon on the map?  Remember, while the desired outcome is to display a popup with options related to controlling the UNPV, the click is on the map, a control serviced by another service (the COP). In an Object Oriented system the UNPV might be a sub-class of a detection so that it would accept the same event and respond a little differently (in a more specialized way). Here, however the COP and the UNPV are completely different services, developed by two different group and maybe even two different companies.

We may be able to dismiss this specific example and just solve it with a specific solution e.g add an ‘if’ statement somewhere to call up the correct commands and to interact with the correct service(s). The problem, however, is that this example is just the tip of the iceberg. For instance: how do we handle security? – do we need to login for each service separately? How do we handle things that all the services need? SOA’s premise is that we’d get a sort of lego-like enterprise where we can compose different business processes easily. Is there any way  we can get that in the  user interface? In summary:

How do you we interact with multiple services, get an integrated, cohesive user interface and still preserve SOA principles and modularity benefits?

 

One option is, as mentioned above, write specific client code. Using this approach “an application”, is any specific composition of services. For the example above, the application would include the two service (COP and UNPV) and a UI that ties them together. The up-side of this approach is that each application delivers a consistent experience for the user. After all, a specific or tailored application can be made to be very cohesive. Additionally there are many tried and tested ways to build flexible UIs with a proper separation of concerns, e.g. using Model-View-Controller and its variations (in a multitude of rich client and web technologies) so we’d probably be able to reuse some of the UI-side logic even going  from application to application. Nevertheless, we do lose on flexibility. For one, any service change that has UI aspects needs to be redone for each of its UI instances (applications). More so, since the UI specifically ties multiple services changes in one service may cause another to mal-function within the unified UI. We also lose on Composability, or the ability to replace services and to create new business flows (relatively) easy. Overall it’s a bad option long-term but it can be made to work as a short term solution.

A related option is taking a similar approach of tying several services together but instead of integrating them on the client side we integrate the services together on the server side. This approach shares it pros and cons with the previous solution. However there are specific circumstances where it does make sense and you can read about them in the next pattern (section 6.5 Client/Server/Service)

Lastly, we have the option to have independent UI components per service. This would overcome the limitations we’ve mentioned above since each service’s corresponding UI can evolve independently and you can just cram a as many of these as you like to create an application. Unfortunately, with all its benefits this is a non even an option here as, by definition, we won’t have the mechanisms for UI components that work cross services. i.e. it won’t actually solve problems like the one in the example and we can’t get a cohesive UI.

6.1.2      The Solution

What we need, essentially, is a way to compose services together while keeping their respective autonomy on one hand and providing mechanisms to glue them together as a cohesive whole – That’s what the Composite Frontend pattern is about:

Apply the Composite Frontend pattern to aggregate services while providing them unified client-side services like layout and theming as well as coordination services for client-side service integration

Figure 6.5 The Composite Frontend pattern. Each Service has a Portlet which is a Service Agent combined with a UI logic (most likely Model in a MVC UI pattern). The UI host provides services for the different potlets to weave them together into a coherent UI.

The Composite Frontend pattern is about taking the ideas (and sometimes the technologies) behind web portal and applying them to SOA services. Web portals provide unified access point that aggregates multiple web pages. They also provide single sign-one and personalization. SOA interfaces need that and more.

The composite front-end pattern is composed of two main components: the portlet and the host. The portlets are the building blocks, “the composites” which are fused together to form the user interface. The portlets are made of at least two components. The user interface logic (views and controllers in MVC lingo). The second component, the service proxy (or agent) , is the more interesting one from an SOA perspective. The service proxy is a client-side representation of a service. The proxy serves as the model for the user interfaces components. It is usually recommended to have a single proxy per service -just like it is recommended for each service to maintain its own data store. Furthermore, from a product management perspective it can be seen as  part of the service itself

The host is the “value-add” part of the composite frontend pattern. The host provides the glue that ties the different portlets into a cohesive whole. As such, the host provides  several roles. Firstly it provides the canvas or surface on which the portlets are displayed. Additionally it controls the life-cycle of the portlets and lastly it provides capabilities (avoiding the loaded term services…)  like inter-portlet communications and single-sign-on.

Lets revisit the problem discussed in the previous section. We had a right-click on a ui component, which should have produced a context menu with options from two services. How would that would with the composite frontend pattern? One option is that a click would be first intercepted by the host which would then dispatch it to any registered portlet. Another option illustrated in figure 6.6 below , is for the click to  be intercepted by the first portlet the Common Operation Picture (or COP), have it notify the host and have the host ask all the iixnvolved portlets to render the right-click menu. The COP portlet should pass enough information as part of the event for the other porlets to be able to do something meaningful with.

Figure 6.6: Sample event flow in a Composite Frontend. Events are intercepted by the user interface components of individuals portlets , The events are transferred to the host which dispatches them to registered protlets for handling. The host can then render the results for display

The composite frontend pattern is a service consumer pattern so the proxy will utilize the various service interaction patterns like saga, request/reply etc. (see chapter 5) and it can benefit from the various service composition patterns like Service Registry and Servicbus (see chapter 7)

You’ve probably notices the use of the term portlets to describe the service agents and you might be wondering why the pattern is named Composite Frontend rather than Portal. The main reason for that is that the pattern can also be used with rich client implementations and not just web ones – let’s explore that further in the technology mapping section

6.1.3      Technology Mapping

Normally, you’d won’t be developing your own Composite Frontend container and instead use existing products that provide the framework and usually the tooling to help build the portlets.

The obvious example for that are web portal frameworks. Modern enterprise web portals usually support anything from JSR 168/286 (Java Portlet specification) to  WSRP (Web Services for Remote Portlet) to open web standards like RSS, plain REST services or standards like open social.  There are a lot of products in this area both commercial like  ibm WebSphere portal server and Microsoft Sharepoint and open source options like Jboss Gatein and Lifray.  Figure 6.7 below show he layout functionality of the UI host as it is implemented in Jboss Gatein

Figure 6.7: The layout capability of a Composite Frontend UI host as it is implemented in Jboss Gatein portal.

Web portals are not the only option for implementing composite frontends. You can also implement the concept for desktop (“rich client”) applications. An example for that is the prism framework made by Microsoft’s Pattern and Practices group. Prism implements the Composite Frontend pattern for both Silverlight and WPF applications. Prism provides all the functionality of a user interface host and lets you write portlets that consume these capabilities. Code snippet 6.4 below demonstrate using an EventAggregator facility that allows inter-portlet communications (such as the one needed for the sample scenario in the map component example above):

Code listing 6.4 Sample use of Prism’s EventAggregator to send events between different porlets unified by the prism shell

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[Export(typeof(SampleView))]
public partial class SampleView : UserControl
{
   [ImportingConstructor]
   public SampleView([Import] IEventAggregator eventAggregator
   {
       InitializeComponent();
       eventAggregator.GetEvent>().Subscribe(OnItemSelectedReceived); #1
   }
   public void ItemSelectedReceived(ItemSelectedEvent item)
   {
     //do something with item...
   }
}

#1 subscribing to an temSelectedEvent. Another portlet can call get on the EventAggregator to get a reference to the event and raise it without knowing if thare are any subscribers

Lastly, in addition to web portal frameworks and desktop framework you can roll your own implementation of Composite Frontend. however, as mentioned above it is usually better to  choose one of the available options as it quite an investment to get it right.

6.1.4      Quality Attributes

Before moving on to the next pattern lets examine some business drives (or scenarios) that can drive us to use the Composite Frontend pattern.

In essence, the main drives to Composite Frontend are flexibility to adding and changing services and the desire for an integrated user interface that feels as a whole Table 6.X provides examples for both quality attributes:

Table 6.3  composite frontend  pattern quality attributes scenarios. These are the architectural scenarios that can make us think about using composite frontend pattern.

Composite Frontend is probably the preferred way to provide an SOA user interface. However one problem we still have to solve with integrating UIs is UIs that are not SOA aware – for instance what happens when we have an existing UI that we want to expose to services? The next pattern will try to answer exactly that.

Vertica is  a columnar database optimized for analytics. In a nut shell, columnar databases allow fast aggregation of  data as well as holding a lot of columns per row – both traits are helpful when trying to report on data (but vey wasteful when you try to do OLTP operations). Autonomy adds to that path analysis and related algorithms to provide insight from stored data. Add that to HP’s hardware capabilities and you can get a high-performance data appliances that can handle large amounts of data efficiently.

HP is not alone in this trend. We see similar moves by EMC which acquired Greenplum followed by  unified GreenPlum/Hadoop  SW-HW solution, IBM acquiring Netezza and  rolling  its own Hadoop version, heck, even Teradata recently acquired Aster Data to bolster its analytics offering. It’s almost like we’re back in the 1950′s with companies creating dedicated appliances instead of general purpose computers.

While Teradata, an NCR spinoff, pioneered this trend, I think Oracle’s introduction of Exadata popularized this trend. Oracle which is probably the leader could (and still can) be sold with any hardware. All of a sudden, with the acquisition of Sun, Oracle started to keep the high-end customers to itself. This was especially a blow to HP considering the first incarnation of exadata ran on HP’s hardware. Anyway, as we saw above, the big vendors* are rushing to build their own “complete software and hardware suits” and HP, it seems, is doing the same. By talking about dropping its PC business HP is trying to pull an IBM (and its Lenovo move) and focus on Enterprise solutions in general and the hot analytics market in particular

Meanwhile I am reading that HP servers are having trouble handling the demand for their tablet dumping - I guess that’s also bad press to the cloud message of HP. I hope their analytics message and solutions will fare better

By the way, for now this is only interesting for larger corporations which are willing to spend the big bucks involved  (e.g. Vertica was priced at 100K$ per terabyte last time I checked). Smaller companies esp. SaaS provider, will probably still solve their big data problems with Hadoop, Cassandra and the like. However as data is more than doubling every two years and as the top-tier market will get saturated, I am sure we’ll start seing offerings with more reasonable price-tags over the next few years.

* You may have notices that Microsoft is missing from this list – MS is also making moves in this field with Parallel Data Warehouse and Dryad . Unlike the other’s they do not have hardware capabilities as well as some other challenges. Maybe I’ll dedicate a post to them in the future.

RabbitMQ is a message bus built in Erlang. It implements the AMQP protocol, which, unlike JMS, is also a wire protocol and not just an API. (meaning you can use an AMQP client with any compliant AMQP server) AMQP has a few concepts which are different from “regular” messaging infrastructures (like MSMQ or MQSeries). The illustration below shows the main concepts of AMQP

Virtual Host – Virtual host is administrative container which  provides access control boundaries. Each virtual host has its own set of exchanges. A connection can only be associated with a single virtual host

Exchange – An exchange is a message routing agent. Exchanges can be temporary, auto-deleted or durable. Messages are published to exchanges and then routed to queues that are bound to the exchange (if no queues are bound the message will be lost).Exchanges support one of the following routing schemes

• Direct – based on a routing key. Any queue (or exchange) binding to the key will get the message
• Fan-out – no routing key , each queue or exchange bound to this type of exchange will get a copy of the message
• Header -  Header based routing allows compound routing based on a combination of lists of identifiers (essentially key-value pairs) the routing can be done on either any or all key-values specified. The subscription then specified a set of key-values and an operator (and or any) e.g. { ‘x-match’ => ‘any’, :customer => ’23′, :agent => ’007′ }. This looked like a promising direction until we’ve found that it isn’t well supported (e.g. it isn’t even documented in the C# documentation of RabbitMQ) and doesn’t perform well
• Topic – Topic based routing allows compound routing based on topic hierarchy. Topics is based on pattern matching (a strong core capability of Erlang, RabbitMQ’s implementation language) and allows versatile subscription based on wildcards: * a single segment placeholder or # zero or more segments  (e.g. foo.*.bar will match foo.baz.bar, foo.bag.bar but not foo.baz.bag.bar, foo.#.bar will match all of them)

Both queues and exchanges can bind to an exchange. The default exchange uses the queue name as routing key (i.e. sends a message directly to a queue)

Queue – A queue is a FIFO buffer. It is important to note that the FIFO order is only guaranteed when a single consumer is used. Queues, like exchanges cab be temporary, auto-deleted or durable. Getting messages from exchanges to queues is done by binding the queue to an exchange.

So that’s a short into to AMQP itself. In the next installments I’ll expand a little about RabbitMQ itself, show some coding samples and finish it up with some pros/cons

illustration by beautyredefined

First off it is a major event since Amazon controls almost 60% of the Infrastructure as a Service market (per WSJ) and an incident like this is bad publicity for the whole cloud concept. After all if Amazon is fledgling what does that mean for Rackspace and the other IaaS players – not to mention PaaS players like Google and Microsoft (since PaaS solutions require more complicated software and higher integration with end-solutions.

It is also worth mentioning that this isn’t the major outages for Amazon. One notable “availability event”  occurred in 2008 where S3 had major problem for about half a day and a few minor problem with EC2 in 2009. What’s stands out here is that the availability zones features that was supposed to isolate this type of breakdown to smaller areas broke and only sites that had data-center redundancy (like Netflix for example) managed to handle the interruption while sites like foursquare, reddit and even, it seems,  a company monitoring cardiac arrests

were all harmed.

Another alarming behavior on the part of Amazon is the lack of transparency / bad crisis management in handling the outage. For example Keith Smith CEO of BigDoor (one of the startups affected by the outage) writes

“Starting at 1:41 a.m. PST, Amazon’s updates read as if they were written by their attorneys and accountants who were hedging against their stated SLA rather than being written by a tech guy trying to help another tech guy.”

When a big supplier fumbles a lot of companies are affected and it is bound to get big press. Also, systems, esp. complex ones, have bugs and its understandable that things may break from time to time (and I am sure that Amazon, which evidently has top talent would find a way to prevent this from recurring). However, Cloud providers need to understand that “with great power comes great responsibility” and the technical offering need to be strengthened with great support and transparency.

On the technical level, it also means that, while moving to the cloud carries a lot of benefits and can save a lot on operations costs, the responsibility for our application’s up time is still our responsibility and depending on the  cost of failure (on the scale from few dollars to lives of people)  we should also architect for disaster regardless of vendor claims. When we build closed systems we may  look at the Mean-Time Between Failure (MTBF and MTBCF) advertised by hardware manufacturers but we’d also add software based reliability mechanisms – for the cloud that may mean cross data-center (region) deployments, cross cloud provider deployments, or even on-premise backup – This is the same measures you’d take when your dealing with the electric company, if it is important enough, you’d install UPSs and generators and alternate sites and whatnot, you just have to figure out how important business continuousness is

I guess we’ll all wait to see how all this unfolds and what will be the after-effects of this outage on Cloud-computing. I personally think that it is still a good move in many cases, however this incident, help focus that the responsibility for our application’s wellness  is still ultimately  ours

Edit Apr. 24th:

I just read a post in Coding Horror which refers to a year old post in Netflix’s blog called “5 lessons we’ve learned using AWS [Amazon WebSevices]“. Netflix, in case you’re wondering survived Amazon’s outage and indeed, in lesson #3 they explain that if you want to survive failures you have to plan and constantly test for it:

Lastly note that in real world scenarios you probably use a mix of simplification, parallel and yes even leaps – We need to have several tools in our tool-set. We can’t afford to just have a hammer since after all, not every problem is a nail – right?

* Architecture definition as it appears in the first post of the series :

“Software architecture is the collection of decisions affecting the system’s quality attributes; which have global effects and are hardest to change. Software architecture provides the frame within which the design (code) is built.”

** The context based routing was added as part of a previous architectural change. I mention this here as it is an example for a simplification – an architectural element that was not part of the original architecture but was added later when the actual need arrived (when we had to support both internal operations as well as 3rd party integration)“Software architecture is the collection of decisions affecting the system’s quality attributes; which have global effects and are hardest to change. Software architecture provides the frame within which the design (code) is built.”

*** illustration source newson6