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.

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.

Related post for lesson 6 #3

I found this short but good explaination of 4 differnet approaches to define how a EBA practice will provide value to the business.  As mentioned in the posting, some can be used in sequence.  An ROI approach can be used to get a practice approved and off the ground, but it must be recognized up front that it is only a temporary approach and migrating to a different model, "Fee for Service" or "Part of the Organization Fabric" needs to be done relatively quickly to ensure the practice is long lived.

http://www.accelare.com/blog/2014/04/03/four-business-architecture-value-propositions

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

Related posting #1

This paper is the result of the SOA Consortium EA2010 Working Group entitled

"Business Architecture: The Missing Link between Business Strategy and Enterprise Architecture".

In touches on some investment and cost analysis benefits of EBA efforts but also goes into relatively deep details of implementing an EBA practive, including establishing the business benefit, executing an EBA practice and itteratively executing and demostrating business value.

It also includes one of the better definitions of Business Architecture that I have seen,

"The formal representation and active management of business design"

http://www.bptrends.com/publicationfiles/THREE%2002-10-ART-Business%20Architecture-Missing%20Link-Michelson_bmm.pdf

Thoughts on Lesson 6 reading

As I read through this week’s material on Enterprise Business Architecture (EBA), I can see the theoretical value of creating Business Architecture models/documentation.  Defining a model of the business, linked to the Business Context can inform the company of how the architecture of their business supports their goals in interacting with the world around it (my definition of Business Context).  However, it seems to me there are two topics missing from the discussion

1. Cost impact analysis


This is mentioned briefly, in respect to helping guide investment dollars to the most positive impact to the business.  However, I think there is a potential for additional benefit.  With the business context defined and linked to the EBA, ETA, EIA and ESA, current state expense analysis could be performed.  I believe this would allow current expenses to be analyzed to see if the ongoing cost of supporting various ongoing operations would provide useful information.  For example, if a sales channel is identified to only support one product, if the product profit does not support that expense, perhaps the product should be dropped.  However, it could also highlight a other corrective action such as opening the channel to other products, or combining to channels.  This type of analysis is of course already done, but having additional viewpoints on the relationships of expenses informed by the linked architectural viewpoints are another benefit of the EBA efforts.


2. Business Architecture knowledge is already possessed by the business


One of the challenges I see with defining the benefit of EBA efforts is much of the information is already known by individual people within the organization.  I believe some of the resistance to these efforts is the fact that when results are presented, individuals state something along the lines of, “you aren’t telling me anything I don’t already know”.  It seems to me that there is some validity to this feedback.  However, the benefit is realized in how the information can be more easily understood by all staff within the company.  This enables more people within the organization to take advantage of it.  I think this is one aspect that is missed in value analysis. 




I also still see a struggle between openly sharing information and keeping close hold of information.  This, strictly speaking, is not a problem specific to EBA efforts, but is one way that EBA efforts can add value by assisting in broader distribution of knowledge.

Interesting post for Lesson 4 #2

This article focuses directly on IT staff training needs beyond just hard and soft skills, but what methods and techniques can be used to help motivate people in a changing environment.

http://www.irma-international.org/viewtitle/51072/

Interesting link related to lesson 4 reading

I thought this article talked about the points I raised concerning the missing focus on managing the people side of any type of organizational change.

http://www.strategy-business.com/article/rr00006?gko=643d0

Thoughts on lesson 4 reading

The hardest part of any change initiative, in my opinion, whether IT or other area, is how the people management aspects are handled.  The thing that jumped out at me is how little of the reading focused on that aspect of the issue.  In my experience it is more about people being worried about their jobs that gets in the way of change rather than complexities or relevant skills sets needed to implement change.  This manifests in 2 different ways

• Passive Resistance: The people who can best contribute to change initiatives, those that know best how things work now and what skills and technologies are available are the ones that are often most at risk.  They can be hard to motivate to contribute to change efforts, so they are less likely to help

o   This can potentially be addressed with abundant training in new technologies, giving opportunities in the new target state

• Nay sayers: These people are often not very good at their current jobs, but have found their niche in the current system.  They may have little to contribute to the target state efforts.

o   This can be partially addressed as above, but other avenues must be made available.  Providing early retirement or transfer opportunities are two possibilities.  One innovative approach from a high performing culture I found is a standing separation bonus for any employee to take advantage of.  The theory is that anyone who can be tempted to leave has not completely bought into the enterprises goals.

Both of the above can be minimized with initiatives related to employee morale and culture.  Including both of these things can help uniting staff in a common goal and helps with change execution.

I did find that two of the optional readings talked a little about this type of issue

•  “Five steps to a faster, better cheaper I&O” identifies the above as one of its identified Key Challenges

Key Challenge: “Achieving and sustaining changes in I&O team behavior is reported consistently as the most challenging aspect of I&O transformation.”

However, I did not see where the paper gave real concrete actions to take to address this issue.

It did allude to how organizations with a strength in some aspects of people management, lated to organizational structures and project management may have developed these at the cost of the wider culture.  This causes imbalance where the overall culture cannot embrace change.   This suggests that there is a link to the broader Enterprise Culture and skill sets to be able to successfully implemented improvements.

Additionally, the paper partially addressed the topic further by talking about the importance of developing and communicating a clear vision of the future state to include required resources and competencies.  This I believe gives people a clear idea of the possibilities they have to be involved in the future.

• “Strategic Technology Planning: Picking the Winners”

This article talks about more details of how new technologies can be brought into the organization, but again, only indirectly mentions the broader context of the organizations ability to change. 

It first addresses indirectly culture as it discusses the broad idea of categorizing enterprises into A, B and C types of “Technology Aggressiveness”.  This categorization seems to at least indirectly show how enterprise culture has an effect on its ability to change.

It later brings up a discussion of how new technologies can be transferred around the enterprise.  It talks about different strategies which can indirectly address the concerns I raise.  The concept of creating an advanced technology group (ATG) and defining various options for moving the technology into the enterprise.  It suggests including staff transfers, ass one such approach.  I believe this is an implementation of part of my theory above.

Interesting Article related to Topic 3 #2

I found this paper very interesting.  It is the Enterprise Architecture Guide for MIT's own systems.  It is more than just strictly an Enterprise Information Architecture, but it contains many EIA elements, including a Logical IA laying out major entities and their relationships, and some systems data flow analysis along with Future State and iterative state planning

http://web.mit.edu/itag/eag/FullEnterpriseArchitectureGuide0.1.pdf

Interesting link related to Topic 3

Here is a paper published by Oracle.  I am impressed that there framework is not just a collection of there products and how they will solve all the worlds problems.  I was drawn to the idea of "Data Realms".  It looks like a good way to think about different types of data a company has and align solutions to these realms while keeping an eye on the Conceptual Level Data entities.

http://www.oracle.com/technetwork/topics/entarch/oea-info-arch-framework-dev-process-513866.pdf

Interesting Link topic 7 #2

This is a video my company put together (I played a small part in developing the script) as part of a presentation we did for a recent Gartner Conference.  I think it is a good, simply worded explanation of what value Enterprise Architecture brings to an organization.

https://www.youtube.com/watch?v=_d6SIkadnGQ

Interesting article related to Topic 7

I found an interesting take on the definition of Enterprise Architecture. The basic premise of the article is that no one is doing Enterprise Architecture, because to architect an Enterprise should mean you design the architecture of an enterprise. However, in reality, an enterprise is not something you can just design as a whole to any point in time. An enterperprise is a continually changing complex system. I would argue based on the discussion in this article, perhaps we could instead talk about the practice of Enterprise Change Management Framework instead of the practice of Enterprise Architecture.

http://zapthink.com/2011/04/05/why-nobody-is-doing-enterprise-architecture/

My thoughts on reading #3

For this week’s reading, the aspect that jumped out at me is the focus on information sharing and breaking down silos.  There are two reasons why this jumps out at me, 1) I have been hearing about this topic since I landed my first job in IT 20 some odd years ago and apparently we have not been able to solve this problem yet and 2) my company is investing heavily in trying to solve this same problem.

I partly see the reason this is still a problem for so many organizations (from past experience) is that to solve this problem, organizations look for a “magic app” or product that will solve this issue by simply buying something.  And I have to admit, that has been my approach to the problem too.  The reading has for me outlined the problem/solution in a more comprehensive way, framing it as an Enterprise Information Architecture (EIA) problem/solution.

There will always be the need to store data in silos (speed of processing, COTS product data schemas, Line of Business custom applications).  But taking this reality into a broad EIA approach provides the methodology to pull them all together into an integrated whole.  As stated in the reading, the key is defining enterprise data in the abstract first and then planning for information sharing and integration approaches.

My company is currently in the early stages of working thought this.  We began development of what we call the Enterprise Data Infrastructure.  From a Business Architecture standpoint, this includes definitions of what our Enterprise Data Objects are (Party, Security, Contract, etc.).  From a Data Architecture perspective, this includes defining separate logical data schemas and physical databases aligning with each of these entities.  From a Technology Architecture perspective, a Data Services layer provides the translation and distribution services to both coordinate data relationships between the different entities, but also with other systems.  Communications with other systems includes definitions of update events to be communicated out to other systems as well as incoming additions/updates/deletes from distributed systems of record.  Rolling this all out involves defining highest priority enties and systems first and enforcing an approach of “getting the data from EDI” whenever it becomes available, in coordination with existing applications’ release schedules

As this is the first instance of an actually concrete solution to this Enterprise level problem, I am curious if others from the class have encountered/developed alternative solutions?

Second interesting article related to Topic #2

Another post I found interesting is a little bit of a tangent to the topic.  The role definitions discussed are very important and they make sense to me.  They also seem like roles that can actually be implemented in real life.

However, in order to make them operationally successful, there is more than defining roles and responsibilities, but there is also the need to create an organizational structure that supports the authority for each role to carry out their responsibilities.  This is one area that I have seen our own organization have trouble with.  The theory of EA's value can run head long into entrenched interests and differences in opinion between Business leaders and EA/IT leaders on the correct direction for almost all IT decisions.  This conflict is further complicated when financial resources/control are taken into account.  Who controls the $$$ wants to control the decisions.

The paper referenced by this link gives an outline for setting up these lines of authority

https://www.cebglobal.com/blogs/3-principles-for-structuring-enterprise-architecture-groups/

Interesting skills description paper related to Topic #2

I found this paper from MIT that seems interesting from the perspective of defining what skills are needed by different EA roles.  It also includes career path recommendations.  Together these could help organizations identify, train and retain the various roles discussed in this week's topic.

The paper includes the 3 roles highlighted in the reading, two using the same name.  Solution Architect and Application Architect are the same and I believe the Enterprise Solutions Archtiect maps to the paper's Enterprise Architect, but not exactly.

https://ist.mit.edu/sites/default/files/about/org/roles/Architecture_Position_Description_v4.pdf

My thoughts on topic #2

The first point that jumped out at me from this week’s reading was the proposed roles of Solution Architect (SA), Application Architect (AA) and Enterprise Solution Architect (ESA) as part of an organization’s Enterprise Architecture (EA) function.  The explanation of the responsibilities, focus areas and deliverables makes lots of sense.  I can see the benefits of dividing the focus on a single applications architecture by an SA, generalized focus on multiple application architectures for a business area of the AA role and enterprise wide application architecture trends and planning focus of the ESA role. 

The issue I have with these definitions are not the definitions themselves.  I find it hard to believe that any organization would establish all of these roles at any given point of their EA program development.  The article did concede that smaller organizations would likely have individual staff performing multiple roles at once.  I think additional research would be valuable into how real organizations divide these roles among their staff.  I would be interested to see how the roles are divided at organizations of similar sizes. 

I would anticipate the results to show that larger organizations would implement the SA and ESA roles, due to efficiencies of scale due to their size supporting more specialization and needs to communicate ESA level concepts across more SA staff.  Smaller organizations would likely not be able to support so much specialization due to their size and communications would need to distribute across a smaller number of EA staff.  I would think smaller organizations would implement the AA role only.

A second piece of the reading that stood out to me was the Application Architecture Future Trend paper describing the experience of Amazon’s architecture development.  Beyond the overall picture presented describing the now trend setting approach of Amazon’s development of AWS, one arguably small detail caught my focus.  Amazon’s approach of developing all functions with APIs for use even by internal users appears to avoid all the weaknesses I have seen in my career in using this approach.

For many years I have seen this approach described as a best practice, but in practice, I have seen it very little.  Further, in my own personal experience, the approach never quite lived up to the theoretical benefits fully.  Primarily, the idea that providing an API interface insulates the participating endpoints from being impacted by each other’s changes never quite work out.  Two main shortcomings I have seen are

• Parameter changes to the API calls drive over time the need to change the calling application, in contradiction of the promise to prevent this
• Additional functionality and data returned from calls causes problems for calling applications when additional functionality and data are not needed

The personal revelation that I discovered in the paper involved the use of XML documents in the API calls.  Formatting parameters as XML documents enable more flexible means of calling the APIs that allow parameter changes without changing the API signature, which addresses my first issue.  And the concept of enabling the caller to provide an XSLT parameter to empower the caller to limit returned data to meet its needs addresses issues with data overload and efficiency was an eye opener.  I will be adding this to my own toolkit.

One big question that was raised for me came from the article “Time to Retire the 3 Tier Architecture”.  The title caught my eye partly because I have already come to the conclusion myself (I think the time is long past actually).  The other part was my own struggle to understand the new environment, specifically when it comes to the Data tier.  Replacing the UI tier due to the changes in UI devices seems easy to understand.  For the mid-tier, replacement also makes sense with the proliferation of SOA services, micro services, etc.  However, I have not seen a good reference architecture for the data tier.  I have some exposure to Big Data and the concept of Eventual Consistency, but not a good detailed architecture for how to implement either as a replacement for a good old fashioned self-contained relational DB.  One main capability I have not seen replicated in other approaches is speed.  Generalized services always seem to be much slower than relational DBs with any large amount of data, and the complexities of managing eventual consistency with all but the simplest data sets seems daunting.

My question is, has anybody found a good reference for what either of these data approaches would look like in a replacement for the traditional data tier?

Second interesting link related to Lesson 1

Our EA 874 lesson for this week included a paragraph talking about in effect "where to Enterprise Architects come from". I came across a thoughtful article that covered more than just background but went into a good amount of depth on what traits and skills a good architect needs.

https://www.linkedin.com/pulse/20140602003935-8960041-the-anthology-of-making-of-an-enterprise-architect

Interesting link related to Lesson 1

As a supplement to my previous post, I found a paper specifically addressing one take on how to define a Security Architecture Framework from the Information Security Society of Switzerland. 

https://www.isss.ch/fileadmin/publ/agsa/Security_Architecture.pdf

The paper contains a nice overview on how to define a specific organization's Information Security Architecture. In particular, it has a different definition of Security Architecture than this week's lesson (however, it does not strictly agree with my own proposed changes in my previous blog).

"A Security Architecture is a cohesive security design, which addresses the requirements (e.g. authentication, authorization, etc.) – and in particular the risks of a particular environment/scenario, and specifies what security controls are to be applied where. The design process should be reproducible."

My thoughts on reading 1

I think my company EA leaders have read the same material that this week's lesson material is based on as it reflects almost exactly exactly the internal structure of our EA division. However we have some variation. Our organization includes the Business, Technology, Data and Security Architecture domains set up as individual groups. However, with Application Architecture, we split this into 5 separate Portfolios, which mirror the major Business Divisions of our company. This is mainly because the first four areas are primarily funded from the central IT budget, where as applications are funded by the corresponding divisions and typically only connect to other applications within the business. This has caused some friction as control of individual application's architecture and budget are closely guarded and acceptance of any central influence over either has not been fully successful in my opinion. This limited success, I believe, was due to the fact that we used a strict governance model. It was seen as nit-picky and a hindrance. We switched to a model where we provide recommendations, with visibility to higher management. It is more of a guilt/peer pressure approach. 

I did have one issue with the lesson. It describes Security Architecture as “the artifacts that describe how the security controls ..." I would strongly argue that Security Architecture in more than just artifacts. A comprehensive Security Architecture includes implementation of implemented security mechanisms, such as Firewalls, intrusion detection, secure development practices, etc. I wonder where Wikipedia would place these components in its EA framework?