EA 874 Blog Topic 3 Data/Information Architecture

EA 874 Blog Topic 3 Data / Information Architecture Layer

Dominic Patruno

Data Breaches

Its difficult to discuss data and information without addressing the ever increasing data breaches. Some being very significant lie the recent Experian data breach. According to reports (WindowsIT) hackers were able to obtain ove 143 million records. This include names, social security numbers, driver license numbers and credit card numbers among other personally identifiable information.

Though the Experian data breach is an extreme case of data loss. Most companies, have some level of exposure when it comes to sensitive data. Most companies, are not even sure where all of the data lives and how it is transported around the company. Companies due implement control measures, such as data loss prevention and information rights management tools, but without proper classification of the data. How does one know when and were to apply the proper policies and controls.

The volume and velocity of data is only growing, and companies will need to have a proper data/information architecture in place to account for this and should start sooner rather than later. I can see where data architecture could be a differentiating factor. If these types of braches continue, government might get involved and require proper controls similarly to what happened with the Sarbanes Oxley act.


Data Architecture

Data architecture has become a very important practice to companies and is important to stay competitive if not relevant as companies become more digitally enabled. 70% of employees have access to data they shouldn’t while 80% of analysts’ time is spent discovering and preparing data (Dallemule & Davenport, 2017).

One the biggest hurdles to implementing data architecture, is where to start and trying to boil the ocean. If companies have not had any real data architecture in their enterprises, then they would want to start small with achievable milestones that deliver the best value for the effort.

Some experts agree with starting with “Single Source Of Truth” (SSOT) data. Usually this is customer, financial and supplier data. Most everyone can agree what system houses this type of data and how it is represented. Another element that will make data architecture successful is data governance.   This is very important, because there should be rules on how data is created, used, labeled and destroyed. This can also help with mitigating data leakage risks.



Another approach is to take either a defensive or offensive position with regards to data architecture and strategy. This could help set the scope and provide buy in and support from senior leaders and executives. The following table illustrates the difference in each position.


The Elements of Data Strategy

KEY OBJECTIVES Ensure data security, privacy, integrity, quality, regulatory compliance, and governance Improve competitive position and profitability
CORE ACTIVITIES Optimize data extraction, standardization, storage, and access Optimize data analytics, modeling, visualization, transformation, and enrichment
ENABLING ARCHITECTURE SSOT (Single source of truth) MVOTs (Multiple versions of the truth)


Data architecture is extremely important and companies that are not taking this data architecture seriously are in danger of being either bought or go out of business. Keep in mind data architecture is something that is iterative and needs to be designed with continuous improvement and agility going forward to be successful.


Data Is More Valuable Than Oil

If we look at some of the biggest tech companies today, Google, Amazon, Apple and Facebook, we can see a patter in how they use data to advance their business. Google with their search engine data, Amazon with their purchasing data, Apple and Facebook with their advertising data and it continues to grow. This leads to companies acquiring more data to make better decisions, which leads to capturing more data to make better decisions.   Along with tools such as AI and Machine Learning this only enhances their knowledge on how to better sell and market to the customers.











Retrieved September 20, 2017 from https://www.washingtonpost.com/business/technology/what-you-need-to-know-about-the-equifax-data-breach/2017/09/09/46d20dc4-957d-11e7-8482-8dc9a7af29f9_story.html?utm_term=.bcb7489a9cec

Dallemule, L. & Davenport, T. (2017, June). What’s Your Data Strategy. Retrieved from https://hbr.org/2017/05/whats-your-data-strategy

Hunt, T. (2017, September). The Trust Problem with Equifax. Retrieved from http://ezaccess.libraries.psu.edu/login?url=https://search-proquest-com.ezaccess.libraries.psu.edu/docview/1936769277?accountid=13158


EA 874 Blog Topic 2 Application Architecture; System Development

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.




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/