A Solutions Architecture aims to address specific problems and requirements, usually through the design of specific information systems or applications, and typically accommodates many different audiences as it addresses direct business and technical concerns without dropping down to the nuts and bolts of the software architecture.

Note, that I provided a link to Wikipedia’s definition, but I have expanded that definition to be more specific regarding its intended audiences and provided level of detail.

It should be noted, that my intention is not to advocate a Solutions Architecture as another tedious task in the software development process, but to provide a software architecture practice that is

• practical and useful by a broad audience,
• flexible in its composition, and
• well understood, especially by business and technical folks.

Many times, I’ve seen the impedance mismatch, e.g., technical jargon, business jargon, expectations, communications, etc…, go unnoticed, or ignored, far too long. A Solutions Architecture provides a proven strategy to effectively guide architecting software systems.

In this post, I delve into the concept of Current State Architecture and Future State Architecture and how identifying these help guide us to the ultimate goal, the Solutions Architecture.  If it is discerned through the Solutions Architecture, that the current state architecture is unacceptable, work can begin on creating the future state software architecture.

Please click on the link if you are looking for information on helping you determine

“When is it time to revisit my current software architecture?” - another post by B. Buikema

Solutions Architecture

A Solutions Architecture is typically written as slides, e.g., a powerpoint presentation, not straight-up, highly-textual, documentation.  It is comprised of content and diagrams that provide a 360 degree view of a software architecture as a total solution.  Details such as algorithms, code snippets, detailed designs (i.e., UML class, sequence, state, etc…) are typically omitted.

NOTE:  Companies typically have business and engineering folks whose tolerance for documentation is either small or large, and this is driven by the company culture.  I recommend that the Solution Architecture is kept as tight and to-the-point as possible to match this tolerance.  However, make sure that any items deemed important by folks are, in fact, included to ensure buy-in by all parties.  I will also identify those items I believe are absolutely necessary.

Typical items found in a Solutions Architecture are

• Statement of Work (SOW)
• Goals
• Considerations
• Use Cases
• Conceptual Architecture
• Logical Architecture
• Security Architecture
• Information Architecture
• Physical Architecture
• Network Operations Center (NOC) Requirements
• CURRENT STATE:  Discussion of Business and Technical Gaps
• FUTURE STATE:  Solutions to Business and Technical Gaps
• Non-Functional Requirements (NFR’s)
• Engineering Development Staffing Requirements (e.g., roles/skills)
• NOC Staffing Requirements (e.g., roles/skills)
• Operations Staffing Requirements (e.g., roles/skills)

SOW

This is the statement of work and is usually a paragraph or two describing the intent of the system or application.

Goals

Provide key goals important to both the business and engineering.

Considerations

Key considerations include, but are not limited to

• targeted business markets/consumers
• targeted technologies/platforms
• keeping legacy features (or not)
• short and/or long-term business plans
• short and/or long-term technical plans
• user privacy policies
• sensitivity to cost and time

Use Cases

These are typically high-level and include all major actors and relevant use cases.  Include all roles and responsibilities, and, if you’re unsure, it is better to include than exclude.

Conceptual Architecture

This is the loosest of the architecture diagrams, but can set the stage for understanding the  other architectural views.

The Conceptual Architecture provides a view depicting high-level, conceptual systems, subsystems, and/or applications, and their importance to the actors and use cases.  This is commonly just arrows from the actors to a high-level component and stating the high-level use case it represents.  There are typically no hard and fast rules in creating a Conceptual Architecture, but it is useful when discussing the high-level architecture.

Logical Architecture

The Logical Architecture depicts the logical view of the system or application and commonly identifies the main software components as follows:

• systems
• subsystems
• applications
• servers (such as email and web servers)
• services

A Logical Architecture need not concern with the attributes of the physical environment.

• data in flight
• data at rest
• authentication and authorization

Information Architecture

The Information Architecture may include core data schemas, data flows, transactions, workflows, etc,… NOTE:  It’s advisable not to delve to deep on these, keep them at high-level to satisfy the use cases and come of the other architecture diagrams.

Physical Architecture

This depicts a diagram(s) the physical environment(s) of the components the system or application is hosted on.  Server nodes, clusters, firewalls, databases, are just some of the components identified.  Details to the physical hosting and interfacing are well established.

NOC Requirements

NOC requires various deployment and topological network diagrams for each environment they maintain to host the system or application.  This usually includes Production, Testing, Staging, and Development.

Discussion of Business and Technical Gaps

This is relevant to the Current State Architecture only (see below).

The business gaps can commonly be captured in a table format, identifying the feature, the problem/challenge, the folks affected, and the priority of importance.

The technical gaps are similar, but describe the technical difficulty, of course.

You can also see how useful this becomes when you map the two together to form an end-to-end understanding of why the business problems/challenges occur.

Solutions to Business and Technical Gaps

This is relevant to the Future State Architecture only (see below).

Taking the details discussed in the Discussion of Business and Technical Gaps, each item should be identified and given a description of the solution along with a measurement of how well the solution solve the actual problem/challenge,

For example, you can adopt 0 – 5, where

• 0 represents no solution,
• 1 represents 20% solved and
• 5 represents 100% solved.

NFR’s

NFR’s typically include details that are not always given to engineering, but are critical to operations

• availability
• disaster recovery
• performance and scaleability
• elasticity
• instrumentation
• data backup and retention

Representing a Solutions Architecture Through States

In order to effectively compare and contrast different solutions architectures, it is necessary to provide a baseline, also known as the current state architecture.  And new solutions known as the future state architecture.  This nicely allows us to describe the state of the union as we see it today, and optional solutions that are possibilities for the future.

Current State Architecture

Simply stated, this is the current state of the software architecture.  In addition to the architectural specifics, the gaps in both business and technical are included.

In addition to the typical items listed above, the following are specific to the current state:

• Business Gaps in the Current Architecture
• Technical Gaps in the Current Architecture

The exercise in creating the Current State Architecture is rewarding as the results make it much easier to justify arguments made in the past that were harder to prove.

Recommendations

I recommend the following, at a minimum, as I strongly believe they are core to defining a Solutions Architecture:

• Statement of Work (SOW)
• Goals
• Use Cases
• Logical Architecture
• Security Architecture
• Information Architecture
• Physical Architecture
• NOC Requirements
• Non-Functional Requirements (NFR’s)
• CURRENT STATE:  Discussion of Business and Technical Gaps
• FUTURE STATE:  Solutions to Business and Technical Gaps

The actual details for each of the above can be brief, as long as any details that can affect the final decision are surfaced enough for clear discussion.  For example, identifying high-level data schema(s) are suffice for the Information Architecture as long as key data stores (e.g., databases) are present in the diagram.

Using the Current and Future State Architectures to Identify the Winning Solutions Architecture

This is where the rubber hits the road and the real decisions can be made.

Now all of the facts are within easy reach to do comparisons and open up discussions that can include both business and technical folks.  This proves fruitful for a company’s future, as the business can share its short and long-term needs and engineering can understand its limitations, if any, and together well-informed decisions can now be made going forward.

Moving Forward

Coming up in the near future, I will discuss using the Solutions Architecture to drive creation of the Software Architecture.

Please click on the link below if you are looking for information on helping you determine

“When is it time to revisit my current software architecture?” - another post by B. Buikema

I also have many other posts regarding

• software architecture
• mobile (Android) development
• enterprise development
• design patterns
• and much more…

so look me up.

See you soon!

In this post, I discuss an important topic in software architecture:

“When is it time to revisit my current software architecture?”

As a software developer, software architect, solutions architect, software product manager, and software consultant (I’ve been all of them), I have to come into companies to help make decisions regarding the future of a current software architecture.  Typically, I’ve seen several camps, but we’ll keep our attention focused on these two:

Startup

Application coded/tested/deployed to early visionary’s specs.  Sales is able to sign up some clients.  Clients report mostly good things about the application.  Venture Capitalists (VC’s) are interested.  Demonstration to VC’s went great and funding approved!  But engineering says

• the architecture can’t scale
• it isn’t robust enough for rapid growth
• it wasn’t designed to do those fancy phase 2, 3, 4, etc…, features, since we were told to get phase 1 out the door asap.

We’ve all been there.  Now what?

Likely problem:  No real software architecture existed in the first place.  Consider this a working prototype, but no more than that.

Mature

Application has been in production for several years and supports our clients, but is horrible to maintain, operate, and extend.  The current technology platform is aging and is stifling the business’s ability to add features that the competition already provides, e.g., mobile support.  The CTO sees a new technology platform that may be the silver bullet to all of these problems.

But what now?

Likely problem:  Software Architecture Erosion.  I’ll discuss this in detail in the next section.

Limitations in the Current Software Architecture – Denial or Reality?

Most software folks know that there are weaknesses in the software.  Some even know, dare I say, that there are weaknesses in their own code!  However, is it really the code, the design of the code, or the architecture?

Keep in mind, the code can normally cleaned up (given time), and the design can be normally cleaned up (also given time).  This is considered re-factoring and is a normal part of software development.

Software architecture can be a different story, however.  Depending on the lack of proper logical layers, violation of architecture patterns, tightly-coupled interfaces, implicit or explicit use of technology platform-specific communications, strong dependency to a specific type of data store, and more, can contribute to a software architecture’s limitations.  These limitations normally result in adversely affecting one or more of the following:

• ability to provide a robust architecture that can handle any kind of stress in both extensibility and resource usage, including any changes to the operating environment, and still provide the desired application functionality
• ability to scale to meet growth demands
• ability to create/extend features without excessively increasing software complexity
• ability to communicate with other software components/technologies
• and more…

Ultimately, this leads to software architecture erosion.

Software Architecture Erosion

Simply stated, software architecture erosion is the deterioration of the software architecture by the cumulative effect of numerous implementation decisions that violate the planned architecture.

Let’s take a look at a typical software architecture as time passes.  Fig 1 depicts the development of new features that are released through new versions.

We’ll also see that during the first three versions, the software architecture has been adhered to as shown in Fig 2.

However, things changed for version 4 and 5, as the business decided to expand into other markets and required some conceptually new features that were not envisioned by the planned architecture.  Fig 3 depicts versions 1 through 5.

As can be seen by the dashed line, the system complexity has increased drastically as the software development team made the decision to violate the planned software architecture in order to accommodate the requested business features.  This is a sure sign of software architecture erosion and puts limitations on future features, release schedules, and more.

One might ask, “Is there a test I can apply to know if there is a need to rethink our current software architecture?”

One can look at

• feature time-to-complete creep,
• guage any increases in frustration in the software development team, and
• readily perform stress and load tests to obtain performance metrics.

One can also identify

• fragmented business logic spread in multiple layers/components,
• tightly-coupled interfaces, and
• technology platform-specific communications.

Keep in mind, the seniors on the engineering/NOC team know many of the limitations.  Don’t kid yourself.  The key is determining how much erosion as occurred and how will affect the business in the near and far future.

Don’t Look Now, but Someone Booked a Meeting During Your Lunch Hour!

So now talk about the limitations of the current architecture are omnipresent.

Time for meetings.

Commonly, I see meeting after meeting after meeting occur, where the business stake holders meet with engineering/IT/QA to convey/capture business needs, while engineering meets with platform vendors to attend presentations.  Usually, a few engineering folks quietly discuss what should really be done.  Sometimes business folks learn of a new upcoming technology, and pass this along to engineering as well.

While none of these are inherently bad by themselves, they do indicate a lack of direction that needs to occur.  Everyone has opinions and ideas that provide fragments of a solution, but collectively, these do not provide a complete solution.  Also, I’ve seen literally hundreds of man hours wasted because these meetings occur, often in silos, and, therefore, folks are not collaborating on

• understanding the challenges and problems with the current application
• understanding upcoming features and future targeted business growth (e.g., 6 mo’s, 12 mo’s, 24 mo’s) that the application must support
• prioritizing and time-lining of the above
• creating a strategy to help discover a solution

A common knowledge of the problem must be understood and shared, and a practical strategy must be identified to facilitate the collaborative discovery of a solution.

The Solution

What it comes down to is understanding all views, or dimensions, of your current software architecture, and conducting an objective review of it by all stakeholders.  You may be thinking,

“How can business folks possibly understand the technical details of the software architecture in order to provide valid input to this important exercise?”

The answer.  Because you will provide a Solutions Architecture that will accommodate many different audiences as it collectively, and without deep-down details, addresses direct business and technical concerns.

In my post, Creating a Solutions Architecture, I delve into the concept of Current State Architecture and Future State Architecture and how identifying these help guide us to the ultimate goal, the Solutions Architecture.

I also have many other posts regarding

• software architecture
• mobile (Android) development
• enterprise development
• design patterns
• and much more…

so look me up.

See you soon!

Enhancements

Therefore, we will implement three major enhancements in this post as follows:

• Process proximity alerts in the background by moving processing to an Android Service.  We will call our service PromityAlertService.
• We will use Android’s built-in NotificationManager to provide true Android notifications that appear and can be controlled within the status bar.
• And we will provide a checkbox in the ProximityAlertSetActivity screen allowing the user to enable/disable alerts anytime.  We will default to disabled to ensure that an alert is not fired immediately (since you are standing in the actual proximity of the alert when creating/editing the alert!).

Moving Proximity Alert Detection Processing to the Background by Creating an Android Service

More coming soon!

Enhancing Proximity Alert Notifications

When we add or save a proximity alert, we add the alert to the LocationManager via our AlertHelper class.  Note:  I have renamed the addProximityAlerts(…) method we used previously, to addProximityAlertsToLocationManager(…) to be more precise.  It is within this method that we add a PendingIntent that will perform a broadcast to our ProximityIntentReceiver (you may recall we created the ProximityIntentReceiver in a previous post).

The ProximityAlertHelper’s addProximityAlertsToLocationManager(…) method is as follows:

public boolean addProximityAlertsToLocationManager(Context caller, ArrayList<ProximityAlert> alerts) {
  if (initialized) {
    String context = Context.LOCATION_SERVICE;
    LocationManager mgr = ((LocationManager) caller.getSystemService(context));

    removeAlerts(caller);

    for (int i=1; i <alerts.size(); i++) {
      ProximityAlert alert = alerts.get(i);

      if (alert.Enabled) {
        Intent intent = new Intent(ProximityAlertActivity.class.getName());
        intent.putExtra("id", alert.Id);
        PendingIntent proximityIntent = PendingIntent.getBroadcast(caller, i, intent, PendingIntent.FLAG_CANCEL_CURRENT);
        float proxRadius = Float.parseFloat(PreferenceManager.getDefaultSharedPreferences(caller).getString("proxradius", "2"));
        mgr.addProximityAlert(alert.Lat, alert.Lng, proxRadius, -1, proximityIntent);
        proximityIntentsMap.put(alert, proximityIntent);
      }
    }
    return true;
  }

  return false;
}

Note that we add the alert’s id field to the intent in line 13.  We will use this later to retrieve the alert object upon processing a proximity alert notification event.

Let’s focus our attention on ProximityIntentReceiver class and discuss one addition to the onReceive(…) method.  We make our notification request to the NotificationManager here, on line 14, as follows:

public class ProximityIntentReceiver extends BroadcastReceiver implements IDebugSwitch {
  @Override
  public void onReceive(Context context, Intent intent) {
    String key = LocationManager.KEY_PROXIMITY_ENTERING;
    Boolean entering = intent.getBooleanExtra(key, false);

    if (entering) {
      ProximityAlert alert;
      try {
        alert = ProximityAlertHelper.getInstance().getAlert(intent.getExtras().getLong("id"));

        ArrayList<ProximityAlert> alerts = new ArrayList<ProximityAlert>();
        alerts.add(alert);
        NotifierHelper.sendNotification(context, ProximityAlertActivity.class, alerts);
      }
      catch (Exception ex) {
        Log.e(AppSettings.DEBUG_TAG, "General failure in ProximityIntentReceiver", ex);
        throw;
      }
    }
  }
}

Note, in line 10 the actual event’s alert object is retrieved using the id field we earlier stored in the intent.

And finally, I have created a helper class called NotifierHelper to handle the heavy lifting of adding a notification to the NoticationManager as follows:

public class NotifierHelper implements IDebugSwitch {
  private static final int NOTIFY_1 = 0x1001;

  public static void sendNotification(Context context, Class<?> activityToLaunch, ArrayList<ProximityAlert> alerts) {
    // String values should be stored in "strings.xml"
    // I show them here for convenience.

    NotificationManager notifier = (NotificationManager) context.getSystemService(Context.NOTIFICATION_SERVICE);

    // Create this outside the button so we can increment the number drawn over the notification icon,
    // indicating the number of alerts for this event.
    final Notification notify = new Notification(R.drawable.android_32, "", System.currentTimeMillis());

    // Add status bar notification
    notify.icon = R.drawable.android_32;
    notify.tickerText = "Proximo has new Proximity Alerts!";
    notify.when = System.currentTimeMillis();
    notify.number = alerts.size();
    notify.flags |= Notification.FLAG_AUTO_CANCEL;

    // Add lights
    notify.flags |= Notification.FLAG_SHOW_LIGHTS;
    notify.ledARGB = Color.WHITE;
    notify.ledOnMS = 500;
    notify.ledOffMS = 500;

// Add vibs
    notify.vibrate = new long[] {100, 200, 200, 200, 200, 200, 1000, 200, 200, 200, 1000, 200};

    Intent toLaunch = new Intent(context, activityToLaunch);
    toLaunch.putExtra("id", alerts.get(0).Id);
    PendingIntent intentBack = PendingIntent.getActivity(context, 0, toLaunch, 0);

    notify.setLatestEventInfo(context, "Proximity Alerts", "You have " + alerts.size() + " proximity alerts!", intentBack);
    notifier.notify(NOTIFY_1, notify);
  }

  public static void clear(Activity caller) {
    NotificationManager notifier = (NotificationManager) caller.getSystemService(Context.NOTIFICATION_SERVICE);
    notifier.cancelAll();
  }
}

Providing the Ability to Enable and Disable Proximity Alerts

Enabling and disabling proximity alerts is a fundamental feature that must not be overlooked.  Let’s first update the ProximityAlert entity to define an Enabled field.  The updates to the class are as follows:

public class ProximityAlert extends BaseEntity<ProximityAlert> {
  private static long nextId = 0;
  public long Id = -1;
  public double Lat = 0;
  public double Lng = 0;
  public String Name = "";
  public String Desc = "";
  public String Expiration = "";
  public int Month = -1;
  public int DayOfMonth = -1;
  public int Year = -1;
  public ArrayList<String> Items = new ArrayList<String>();
  public boolean Enabled = false;
  public boolean IsNew = true;

  public ProximityAlert(long id, double lat, double lng, String name, String desc, int month, int dayOfMonth, int year, boolean enabled) {
    this.Lat = lat;
    this.Lng = lng;
    this.Id = id;
    this.Name = name;
    this.Desc = desc;
    this.Month = month;
    this.DayOfMonth = dayOfMonth;
    this.Year = year;
    this.Enabled = enabled;
  }

  public ProximityAlert(double lat, double lng, String name, String desc, int month, int dayOfMonth, int year, boolean enabled) {
    this(nextId++, lat, lng, name,  desc, month, dayOfMonth, year, enabled);
  }

  public ProximityAlert(long id, String name, String desc) {
    this(id, 0.0, 0.0, name, desc, Calendar.getInstance().get(Calendar.MONTH), Calendar.getInstance().get(Calendar.DAY_OF_MONTH), Calendar.getInstance().get(Calendar.YEAR), false);
  }

  public JSONObject serializeToObj() {
    JSONObject serializedObj = new JSONObject();
    try {
      serializedObj.put("Id", this.Id);
      serializedObj.put("Lat", this.Lat);
      serializedObj.put("Lng", this.Lng);
      serializedObj.put("Name", this.Name);
      serializedObj.put("Desc", this.Desc);
      serializedObj.put("Month", this.Month);
      serializedObj.put("DayOfMonth", this.DayOfMonth);
      serializedObj.put("Year", this.Year);
      serializedObj.put("Enabled", this.Enabled);

      ArrayList<JSONObject> itemObjs = new ArrayList<JSONObject>();
      for (String item:this.Items) {
        JSONObject serializedItemObj = new JSONObject();
        serializedItemObj.put("Item", item);
        itemObjs.add(serializedItemObj);
      }
      serializedObj.put("Items", new JSONArray(itemObjs));
    }
    catch(Exception ex) {
      if (debug) Log.e(AppSettings.DEBUG_TAG, ex.getMessage(), ex);
    }

    return serializedObj;
  }

  public ProximityAlert deserializeFromObj(JSONObject obj) throws JSONException {
    this.Id = obj.getLong("Id");
    this.Lat = obj.getDouble("Lat");
    this.Lng = obj.getDouble("Lng");
    this.Name = obj.getString("Name");
    this.Desc = obj.getString("Desc");
    this.Month = obj.getInt("Month");
    this.DayOfMonth = obj.getInt("DayOfMonth");
    this.Year = obj.getInt("Year");
    this.Enabled = obj.getBoolean("Enabled");

    if (obj.has("Items")) {
      JSONArray jsonObjs = obj.getJSONArray("Items");
      this.Items = new ArrayList<String>(jsonObjs.length());
      for (int i=0; i<jsonObjs.length(); i++) {
        JSONObject itemObj = jsonObjs.getJSONObject(i);
        this.Items.add(itemObj.getString("Item"));
      }
    }

    return this;
  }
}

The highlighted lines above represent the changes required to support the Enabled field.

Now we take a look at how the Enabled field is used within the ProximityAlertHelper’s addProximityAlertsToLocationManager(…) method.  Line 9 below now requires that the alert be enabled before adding it to the LocationManager.

public boolean addProximityAlertsToLocationManager(Context caller, ArrayList<ProximityAlert> alerts) {
  if (initialized) {
    String context = Context.LOCATION_SERVICE;
    LocationManager mgr = ((LocationManager) caller.getSystemService(context));

    removeAlerts(caller);

    for (int i=1; i <alerts.size(); i++) {
      ProximityAlert alert = alerts.get(i);

      if (alert.Enabled) {
        Intent intent = new Intent(ProximityAlertActivity.class.getName());
        intent.putExtra("id", alert.Id);
        PendingIntent proximityIntent = PendingIntent.getBroadcast(caller, i, intent, PendingIntent.FLAG_CANCEL_CURRENT);
        float proxRadius = Float.parseFloat(PreferenceManager.getDefaultSharedPreferences(caller).getString("proxradius", "2"));
        mgr.addProximityAlert(alert.Lat, alert.Lng, proxRadius, -1, proximityIntent);
        proximityIntentsMap.put(alert, proximityIntent);
      }
    }
    return true;
  }

  return false;
}

And lastly, let’s see the actual enabled field within the ProximityAlertSetActivity screen.

Addition of Enabled Field into ProximityAlertSetActivity Screen

Note that the details of integrating the enabled field into the application are straightforward, and begin as follows:

boolean enabled = ((CheckBox) findViewById(R.id.CheckBox_alert_enabled)).isChecked();

I hope this discussion of enhancements to the Proximity Alert Mobile Application helps extend your understanding of how to properly build proximity alert applications using the Android platform.

I look forward to discussing new mobile development concepts in my next post!  Please come back soon!

This article helped me immensely, and I thank those guys a lot.  http://www.bleepingcomputer.com/virus-removal/remove-security-tool.  I followed their steps, but had to try several times to successfully run a recommended batch file designed to kill all malicious processes.  Without successfully completing this, you will never rid yourself of the virus.

I finally got through it, and the subsequent steps were easy to complete.  Note that it takes 2-3 hours to run an app designed to identify all malicious files on your hardrive.  Once the task is done, you simply click a button to delete them and viola, you are clean again!

I want to add this link to Malwarebytes, the malware detection and removal software I now run on my computers.  It is extremely cheap, great at what it does, and does not act like a virus itself, like some other malware detection and removal products.