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