Topic #3 - Information Architecture

The State of Information Architecture

In Walker (2015), he surveys a group of around 40 enterprises from all different industries, sizes, maturity levels and geographies about the state of their information architecture. The results are interesting and even spot on in terms of my organization.

The first question deals with the level of impact Enterprise Information Architecture (EIA) has delivering business driven outcomes. The chart below from the article shows that while 90% think it is "ideal" or "significant".



I would agree that we have this same kind of thought in our organization. However, I think we also have trouble understanding the impact that good information architecture would have on our organization. We have completed assessment from Gartner & Hackett and both a reviled that we need to have better data management.

The second question asked about the current state of the enterprises' EIA practice. In the article, it states that "only 16% felt that EIA as a practice had been fully implemented or mostly implemented.



Again I would agree with this from our company prospective. We have not implemented an EIA program. I will be working with our organization to start looking at how we implement an EIA. We have tried to do some governance activities in the past around data management and they have been less than successful. I think if we had a larger of view of EIA then the governance program would be easier to tie directly back to why we are trying to implement such controls.

Walker (2015), goes on to ask what level of impact does EIA have on major efforts like Big Data and traditional MDM and 96% of respondents answered "ideal" or "significant". Again after reviewing other notes around EIA, I also feel that a good EIA program could have significant impact on those efforts. It seems to give everyone a path to walk towards a common goal and highlights the importance of good information management.

The final question was centered on trying to agree on a good definition for EAI. According to the article, "60% of respondents they felt that this definition represented enterprise information architecture:

Information Architecture is an aspect of enterprise architecture that enables an information strategy or business solution through the definition of the company’s business information assets, their sources, structure, classification and associations that will prescribe the required application architecture and technical capabilities."

I feel that that is an adequate definition for EIA.

It is clear that EIA is important and we need to be focusing on how to develop EIA in our organizations. Walker (2014), finishes the article with an important summary:

"However what this data does tell us is that while EIA is important (or maybe even critical) we still don’t have:

• A collection of proven practices 
• The right structures and framing for the EIA space 
• Proven methods that result in predicable and predictable outcomes 
• A clear organizational and competency structure for EIAs" 

Reference
Walker, Mike (2014). The State of Enterprise Information Architecture. Retrieved September 23rd, 2016 from http://blogs.gartner.com/mike-walker/2014/07/23/the-state-of-enterprise-information-architecture/

Data is NOT Information
In the article from Aitken (2015), he attempts to clarify why data is not information. I really like his example of how data without context has no value. The example is this, "take a column of floating point values in a database table – while a developer might be able to discern something about the meaning of the values by physically inspecting the database table and column names – the values are meaningless to the naive user until they are presented on a computer’s screen in a field labelled 'Cholesterol level (mg/dL):'"

I believe we have the issue that data loses its context shortly after it leaves the source system. While the data may be extracted with column names like indicated above it doesn’t take much for someone to manipulate those column names and give the data new meaning in a new context. We have a classic example with the "number of customers" question. Being a utility company, I would say the number of customers would be the number of service points that we currently maintain. Those service points might be active or inactive so not all service points would be related to an active customer. Another point of confusion is that if you don't spell out that one customer can be responsible for multiple service points you can end up with too many or too few customers. So for this example the context should be "customers as number of service points", however many times the number gets labeled just as customer losing the full context of the data.

I like the idea of information asset as spelled out by Aitken (2015). He states that like other assets information assets have value and a life-cycle. I think it is important to label the value of information in terms of data otherwise we end up just storing everything because "storage is cheap." The idea that information has a life-cycle is an interesting concept and I would like to explore that further in our organization. I think the idea certainly is valid as we have data like customer that expires after a certain period in time. Once we have a customer they might not always be a customer so at some point that information would expire.

I'm going to be spending time with my team to help build up the idea of EIA and how we improve our understanding of information within our enterprise.

Reference
Aitken, Chris (2015). Data is NOT Information. Retrieved September 23rd, 2016 from http://enterprisearchitects.com/data-is-not-information/

Why EIA Matters
I have read a couple blog articles from Seth Earley and like the content he provides. In Earley (2013), he talks about getting back to the basics and talks about taxonomy. He continues to talk about two core artifacts needed to improve EIA. Those two artifacts being a good enterprise taxonomy framework and a domain model. After reading a few of his articles on taxonomies those two artifacts started to make more sense.

In our organization we have a good understanding of what we do in various area, however we lack an overall model of what high-level interactions are needed to run the business. I feel we have maybe approach our data governance from a slightly wrong angle. I think we need to address the overall view of the business and build out our enterprise taxonomy and establish a domain model that represents our enterprise. I think doing this will help move our data governance efforts ahead in a way we haven't seen before.

In Earley (2015), Earley tries to reestablish the definition of a taxonomy. I agree with his statement as an IT professional it is way too easy to get into the weeds of the data of an application or system instead of trying to address the higher level abstract perspective needed to build an enterprise taxonomy. This article help me understand how to look at an enterprise taxonomy and how to potentially use it at my organization.

Reference
Earley, Seth (2013), Why Enterprise Information Architecture Matters. Retrieved September 23rd, 2016 from http://www.earley.com/blog/why-enterprise-information-architecture-matters

Earley, Seth (2015), Why Information Taxonomy Must Represent the Landscape of the Business. Retrieved September 25th, 2016 from http://www.earley.com/blog/why-information-taxonomy-must-represent-landscape-business

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

Topic #1 - Enterprise IT Stack

New Continuous IT Stack

I thought article from Wall (2016) was interesting and very now.  He talks about how the IT stack has changed with the on slot of connected devices and the need to keep up with the changing IT landscape.  Development within the IT stack now is measure in weeks and months instead of months and years.  Organizations must learn how to adapt to the new IT stack leverage continuous development and the stressed the need for DevOps. 

DevOps is relatively new to me and is an interesting concept and especially challenging in a very lean organization.  It almost leads me to think there might be a sudo layer not included in EA that has to do with the "people layer" of the organization.  Organizations need to evaluate if they have the right talent to move from the legacy IT stack to the new continuous IT stack.  This is certainly a challenge and will need some analysis from organization to organization.

I like his comparison of the IT stack rule with the rule defined in Isaac Asimov's, "I, Robot".

The Four Laws of Continuous Everything

1. No appdev process shall be implemented that can't be fully automated.
2. If an app, or process, can be rewritten to take advantage of new technology and improve its operation or maintenance, it should.
3. When an app, or process, can be replaced with a third-party service, it should.
4. When the Second or Third Law are limited by the First Law, look to the Second and Third Law to automate more.

This is certainly something I will start incorporating in my think about the continuous IT stack and how we need to start moving towards a more dynamic and agile architecture.

Reference

Wall, Quinton (2016). How to succeed in the new connected-everything continuous IT stack..  Retrieved August 28th, 2016 from http://www.infoworld.com/article/3024257/mobile-technology/how-to-succeed-in-the-new-connected-everything-continuous-it-stack.html

Layers in EA

I found this article from Graves (2013) interesting as it challenges the idea of layers in EA.  He shows the layers from Archimate, TOGAF, Zachman and ADM which can have any where from 3 to 5 layers (Data, Information, Data, Application, Technology.)  Some of the frameworks will combine or split out layers as needed.  He also goes on to say with Zachman you can have more layers depending on interpretation.  He goes on to say, "the correct answer to the 'how many layers' question is 'none."

Graves feels that using layers can have unattended consequences and can be misleading when looking at a particular view.  He uses the "Penrose Triangle" as an example of how things can look correct from one viewpoint but not from another.  I think what he is saying you can't just look at architecture from a single viewpoint and you need to make sure to use the full context of the enterprise.

I'm still digesting his article as it has a great deal of information in it and really challenges the idea of using layers.  While at this point I think viewing EA in layers is very beneficial, I will continue to digest his article and see how his perspective might be beneficial.

Reference

Graves, Tom (2013). On layers in enterprise-architecture.  Retrieved August 31st, 2016 fromhttp://weblog.tetradian.com/2013/12/11/on-layers-in-ea/

Security at an Integrated Layer

Like most people outside of the Security team, I get frustrated when "Security" requires additional to application development, integration or wants to know how data is protected.  I think this article from Rerup (2016) starts to highlight why the frustration exists.  Like the article suggests, Security many times is an afterthought or something that is reviewed prior to production deployment.  While I do get frustrated with security requirements, it is becoming more an more important to include security as an integrated layer in all layers of EA.  I like how Rerup positioned Security Architecture as a part of Governance Strategy, this gives it a more arching view then making it just another layer. 

He goes on to talk about how each layer of the IT stack has some sort of security aspect that needs to be addressed.  I think we need to start embracing security and make sure it is an integrated part of the whole EA framework. Every organization is one breech way from being out of business or taking a large integrity hit.  It is no longer enough to be security conscious, we need to bake in security to all of the business processes and not skimp on the details.

In my organization we are working evaluating the SANS Top 20 and will spend the next 3 years baking those best practices into our architecture to make sure we are doing everything to protect our organization from a potential future breech.

Reference

Rerup, Neil (2016). Why is Security Architecture separated from other Architectures? Retrieved August 31st, 2016 from https://www.linkedin.com/pulse/why-security-architecture-separated-from-other-neil-rerup