Andrew's Blog

Tuesday, December 13, 2016

Intersting link #2 - Lesson 5

An interesting Security Architecture cheat sheet.

https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet

Interesting link #1 - Lesson 5

The first article is a good outline of Security Architecture, It is a little old, being from 2007, but is still seems relevant.

https://iaonline.theiia.org/elements-of-a-good-security-architecture

Lesson 5 Thoughts

In reading the Lesson 5 material on security architecture, I found a couple of the articles especially interesting.

In the ISSS “What is Security Archtitecture” I found a well rounded explaination of a security architecture, with one big difference from most other explanations. In the condenced definition at the beginning of the article, it specifically DID NOT include “documentation” in the definition. This has become one of my pet peeves. It seems in academic circles at least, most of the definitions of various architecture domains refers to it as the “documentation” of various characteristics of the organizations environment. However, most organizations balk at paying for documentation, as in and of itself, documentation does not provide value. But I argue, along with the ISSS, that an architecture is the Design of various aspects of an organization. I also further argue that an architecture is not just the design, but also other implemented aspects of the organization that can be repeated efficiently in multiple parts of the organization to support business strategic goals. For example, common goals are cost efficiency and agile response to changing environmental change. The paper also touches on how to ensure security architecture alignment to business strategy

The article “Analyze the Risk Dimensions of Cloud and SaaS Computing” also caught my eye as our company has made Cloud hosting of our applications a high priority. We have struggled with some of the things mentioned.

The discussion of the difficulty of assessing risk with the various levels of external exposure and traditional vs cloud hosting was a different look at familiar topics for me.

However, the section “Identify and Analyze the Chain of Providers” I found interesting not for the content directly (discussing the need to evaluate all the layers of vendor involved in the cloud service), but in what I believe this relates to in reality. One of the early knocks against cloud was the perceived risk of not having the physical infrastructure and data under your own company’s control and further, potentially mixed with other cloud providers’ clients. Especially in an IaaS Cloud model, what is to say other clients’ applications hosted on the same cloud infrastructure was not malicious? I agree that there is some increased risk, but not as much as perceived. In reality, most organizations have already outsourced most if not all of their IT work to contractors and consultants. These resources may have various contractual clauses to hold them accountable. But, how is that situation much different than the Cloud hosting model? The administrative resources are already exterior to the company.

Sunday, December 4, 2016

Lesson 7 thoughts

This week’s reading entitled “Evaluating Emerging Technologies, Innovations & Trends” focuses on how an EA practice can help an organization better take advantage of new opportunities and provide more value to its customers. These opportunities come in many flavors. Opportunities can include development of new products (business focus), updates to currently offered ones (business focus), changing the company to provide these new/updated products faster (organizational focus), reduction in cost to produce products (IT/other focus), just to name a few. Some of these opportunities can be handled by traditional IT groups, but many require a new approach. There are many approaches or models that can be used, and all of these approaches are related to each other and affect each other.

To me, one common theme stands out. That is the importance of how the people of an organization themselves identify and execute innovation within the organization. It is more about how people approach innovation than about the details of the innovations themselves.

Focus on people starts in the first article, “Foster Innovation Within Your IT Operations Organization”. It makes very good points about challenges IT faces with innovation efforts, many of which are normally ignored because they are “in the weeds”. Some of the ideas have been covered many times, the idea that IT is no longer the “only game in town” for IT services and the lack of sandbox areas for IT staff to “try out” new ideas for example. However, I was very interested in the discussion of how financial incentives can actually work against innovation in IT operations. Salaries linked to frequent delivery without also including focus on innovation will result in high focus on repeating the “way it has always been done” faster and faster rather than taking some extra time to provide value added innovation was novel to me. Also, I had not personally thought about how the type of work done in IT Operations can also de-motivate innovation. I view IT staff in general as great sources of innovation as people, but as the paper pointed out, the tedious nature of operations work can lead to staff falling into a rut and loosing focus on innovation. The reference work “the candle problem” shed further light on the subject for me. It suggested to me the benefits of “getting out of your comfort zone” as a way to increase the likelihood of identifying beneficial changes.

Looking further into the people aspect, in “Determining How and Where Innovation Fits Into Your IT Strategy” makes additional good points about how innovation in IT has to be focused on the people in the organization. Innovation is not something that can be just “bolted onto” strategy efforts, it has to be incorporated into what everyone does in building the strategy. In addition, it is not just Technology, but other aspects of the organization (managerial, business model, cultural, etc.) are also innovation contributions IT can provide, which further emphasizes people.

I felt the article “Six Styles of Technology Innovation Groups” is a good training opportunity for how to work with various stakeholders making innovation happen. I do disagree with the paper’s premise that a group should choose one style. It seems more to me the different styles are better to be used in different situations, rather than an overall singular group overall style. I can see using the Counselor style when dealing with Executives and a Conductor style when working with a group with innovation efforts underway and spread their innovation further and use the scholar style when a new technology is identified that can provide competitive advantage. I think it would be counterproductive to follow only one style.

And finally, I have to admit I was inspired by the Atlassian case study. My former tech-geek self developed the urge to apply to work there. However, I do believe this approach is a perfect case situation. I believe as the company becomes more established in its market, it will be a challenge to maintain their high focus on innovation.

Saturday, November 5, 2016

Link related to Lesson 6 #2

Another paper I thought expanded on this week's reading is this from the Business Archtiecture Guild, titled

"Linking Business Models with Business Architecture to Drive Innovation"

It focuses more on innovation investment but does give a good example of artifacts linked together to form a multi-leveled EBA. It also goes into details about how the lined perspectives can assist in highlighting the most impactful innovations for the business.

http://c.ymcdn.com/sites/www.businessarchitectureguild.org/resource/resmgr/LinkingBusinessModelsB.Arch.pdf