Dominic Patruno

What is SOA

Service Oriented Architecture (SOA) is an architecture that uses micro-services to perform functions that are very targeted and leverage pre-existing functions or applications. Service is the key word, because it amounts to value and that is what people are looking for. If you have a service that provides value, then your service will be consumed. Application Architecture is understanding how all the application and service built to consume and provide end users the value with the applications.

 

Service oriented architecture’s main purpose is to deliver business alignment and value. By leveraging other applications, data and services, SOA can deliver value as it is needed and as it continues to evolve. For example; Netflix has a customer database that stores all information bout the customer and their viewing habits. When building microservice like recommended viewing, the micro-service application might leverage data on what is in the viewing habits database, what is in the recently view database and what is in the like/disliked database. The microservice can then leverage the application and databases to provide a recommended list. This micro-application would be completed independent from the other systems and therefore could be enhanced and updated regularly. This level of customization the customers is very powerful and can separate a company from being successful or not.

 

Build vs. Buy

When considering a new system solution, there are many things to consider. Should you build the system or buy the system. The decisions should support business needs and requirements and should also fit within a budget and timeline. As documented in the TechRepublic web site by Dan Oliver, he outlines six steps to consider before making that decision.

Step 1: Validate the need for the technology -In some cases companies evaluate software and are sold on the multi-functional capabilities and the awe-inspiring success stories. So, these technologies can be purchased and then shelved. Causing companies to waste time and money.

Step 2: Identify core business requirements –  Most companies including mine is guilty of trying to find a technical solution before identifying the business requirements. We lost sight that technology is supposed to enhance our business not dictate the business.

Step 3: Identify architectural requirements – Architectural requirements are good to have because they set standards that designs must adhere to, resulting in reduced cost of implementation and support.

Step 4: Examining existing solutions – in some cases companies are so large that there might be a system in the organization that might meet these business requirements and could be leveraged by extending licenses or purchasing more capacity for the additional users.

Step 5: Are there in-house skills to support the custom solution – most companies may not have the proper skills to build and support this internally. Or in some cases to save money, companies might cut corners and do best effort in development and support. This usually means the quality suffers and users have a hard time using the system.

Step 6: Does a COTs Solution meet the needs – if the company does not have a significant development capability, then a COTs solution is probably the way to go. The implementation costs might be more up front, but over the longer term, a COTs solution could be less.

 

What are Microservices

Microservices are loosely coupled applications which implement a business capability. Another component that meets the definition is continuous delivery and of applications and functionality. The reason to use microservices is when you need to create application that do specific functions that may change frequently requiring less re-writing of an entire application stack.

The small code base and easily scalable design allows for changes to be without impacting the entire service being delivered. Monolithic applications will still be needed and have specific requirements, but more microservice applications are able to leverage these systems in a way to deliver quick and relevant value.

 

 

References

Retrieved September 13, 2017 from https://en.wikipedia.org/wiki/Service-oriented_architecture

Sprott, D. & Wilkes, L. (2004). Understanding Service Oriented Architecture. Retrieved from https://msdn.microsoft.com/en-us/library/aa480021.aspx

Oliver, D. (2002). Buy vs. build: Six steps to making the right decision. Retrieved from http://www.techrepublic.com/article/buy-vs-build-six-steps-to-making-the-right-decision/

Nemeth, G. (2014). What you should start using microservices. Retrieved from https://blog.risingstack.com/why-you-should-start-using-microservices/