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?