Topic #2 - Application Architecture

Don't Ignore Application Architecture This is something I have been struggling with after getting introduced to the concept of micro services. When attempting to split out services into smaller more manageable pieces other things become a bit harder to manage, like security. There are certainly tools that can help you manage all of these new service and really to be effective you would need to implement something like an "API Manager" tool to help. As an example if you take a SOAP web service that has 10 methods contain within it and make each one of those 10 methods its own micro service you now have 10 end points to manage security on instead of just one.

This brings me to my first question for the class, has anyone started implementing micros services or have a large service catalog they have to maintain? What tools do you use to help maintain security or even the dictionary of these services?

I have another example were we failed to keep application architecture (maybe slightly technology architecture) in mind. We purchased a large work management software package and when it came down to the final selection between the top two the one that was selected we selected because it was slightly more user friendly. One big over sight that the application ran on AIX hardware which required physical servers. This decision was not fully considered as part of the discussion. The reason it was not the best decision is because nearly all of our servers run in a virtual environment which please heavily into our disaster recovery strategy. Luckily the vendor had a new version of the application to be release prior to our go live date so we decided to delay the project a couple months so we could take advantage of the new Linux based version.

Reference Stangarone, Joe (2013). Application Architecture: Ignore at your own risk. Retrieved September 11th, 2016 from http://www.mrc-productivity.com/blog/2013/03/application-architecture-ignore-at-your-own-risk/

Decoupling your Application Architecture Even though this is a short article I think it still rings true. Garrett (2016) reminds us to "Decouple Everything!".) While this can be difficult sometimes it is certainly something to remember as we are architecting solutions to fit business needs. Garrett (2016) gives us three things to remember:

1. Any integration model that assumes or imposes that one service know about another, or respond synchronously to another is often a sign that you have imposed unnecessary coupling. 
2. Any application interface that directly reflects the architecture or data model of a backend resource will lead to functional dependencies in the future. 
3. Any business event that maps to data that multiple applications or services must leverage, suggests that an event-driven architecture is the best choice. 

We are starting to see benefits from using integration to decouple our applications. We are in the process of implementing a new work and asset management system and we are taking this approach. We are attempting to keep everything asynchronous and make everything we can a service (where it makes sense.) We are attempting to also take event driven integration into consideration from systems like Finance and Budgeting where things have always been very specifically design for the need. I have asked our developers to think about only delivering their data to a middle point and not worry about what the end system needs, again to a degree, you need to know a somethings about the destination. It has been a challenge to change some minds but we are starting to get people to understand how we want to decouple our integrations between systems.

Another question for the class would be, what kind of luck have you had in decouple application architecture and what have your communication methods been?

Reference Garrett, Ross (2016). Decoupling your Application Architecture. Retrieved September 11th, 2016 from https://www.pushtechnology.com/blog/decoupling-application-architecture/

Four-Tier Application Architecture I have been out of application develop realm for a bit. I'm sure I have encountered the Four-Tier Architecture before but I don't recall it off had. Nommensen (2015) expands on article by Forrester Research which splits out the application layers into four distinct layers.



It is an interesting concept and I'm curious if anyone has actually seen or implemented this architecture in an enterprise setting.

We are still using a three-tier architecture for most of our development but I could see where focusing on a client tier could be beneficial. We have decided to focus specifically on responsive design when it comes to our web development. Most of our integration is internally focus and doesn't need to have a major focus on the client tier.

This is certainly some to keep into consideration for future architecting efforts.

Reference Nommensen, Patrick (2015). It's time to Move to a Four-Tier Application Architecture. Retrieved September 11th, 2016 from https://www.nginx.com/blog/time-to-move-to-a-four-tier-application-architecture/

Schadler, Ted (2015). Mobile Needs A Four-Tier Engagement Platform. Retrieved September 11th, 2015 from http://blogs.forrester.com/ted_schadler/13-11-20-mobile_needs_a_four_tier_engagement_platform?utm_source=time-to-move-to-a-four-tier-application-architecture&utm_medium=blog