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