When I decided in the Spring to embark on the journey of obtaining my Masters Degree, I spent quite some time researching the different fields that were possible options.  One of the key requirements was the need to be completely virtual, as it would be practically impossible with my work schedule and business travel to be able to attend a live classroom program, let alone finding the right program within a reasonable driving distance.  After a lot of research into different programs and different schools, I finally choose the MPS in Enterprise Architecture program from Penn State’s WorldCampus (online school).  MPS stands for Masters of Professional Studies, which, compared to a typical Masters of Science degree, is more practical versus theoretical in nature. (https://en.wikipedia.org/wiki/Master_of_Professional_Studies).

What is Enterprise Architecture and why is it important?

So lets first define what Enterprise Architecture is not:

While that may be an architectural diagram of the Starship Enterprise, it is not what I am studying….   (even though spacecraft engineering and design would be really cool…!)

So, then, what is Enterprise Architecture (EA)?

Here are some more formal definitions found from a few organizations:

• Gartner – Enterprise architecture is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. (http://www.gartner.com/it-glossary/enterprise-architecture-ea/)
• MIT Center for Information Systems Research – The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model. (http://cisr.mit.edu/research/research-overview/classic-topics/enterprise-architecture/)
• Microsoft – An enterprise architecture is a conceptual tool that assists organizations with the understanding of their own structure and the way they work. It provides a map of the enterprise and is a route planner for business and technology change. (https://msdn.microsoft.com/en-us/library/ms978007.aspx)

The easiest way to describe EA is the intersection of Business, Strategy and Technology:

As we studied in our previous class (EA-871), the foundation of Enterprise Architecture is that it holistically links strategy, business and technology.  From a top-down perspective, EA helps to ensure that strategy drives business and technology planning.  From a business perspective, EA provides the context and purpose of business activities by ensuring technology is implemented only after business requirements have been identified and defined. And from a technology perspective, EA provides the strategy and business context for resource planning (Bernard, An Introduction to Enterprise Architecture, 2012).

So what now?

As I read through the course materials for this week, a couple of statements stood out.

1. “Building a foundation is not a quick or easy process.”
2. “EA is a process of progressive decomposition. A best practice is to start with a very generalized vision and develop increasing levels of detail as needed.”

The experience of many companies has proven that very few EA implementations work perfectly from the beginning.  There will be failures. So if we work hard to develop the “perfect” and/or “complete” EA framework, not only will we inevitably fail, but we will have lost our perspective of what’s important and it will have taken so long that our results will no longer be seen as relevant.

I have seen this last result many times in a number of the jobs I have worked.  You put in a request for a very specific change, and, by the time the responsible party actually gets to the change and gets it done, it’s no longer needed. In my current role, my  developer team focuses on smaller iterative programming changes so that, not only do we get results quicker, but we get feedback from our customers faster as well.  If we wait for 12 months before releasing a software patch, some of our customers will have forgotten that they had an issue because they came up with a workaround in the meantime.  By releasing more frequent patches, we can resolve issues faster and have more constant user feedback, which in turn helps us release a better product. Of course, too frequent can be its own problem due to constant updates and business downtime, but that’s a different issue….

I can see EA having the same challenges during a new implantation. EA becomes a buzz word at the beginning of the project with high expectations from all the stakeholders, but, by the time actual results occur, everyone has already lost their momentum. By aiming for smaller and more achievable goals, the results can quickly be tied to improvements in the business processes and the value of the EA program is rapidly recognized.

This goes back to the concept in Scott Benards’ “An Introduction to Enterprise Architecture” where he frequently used a home architecture metaphor to represent EA.  If we are planning on building an entire house from scratch, we don’t wait until the entire construction is complete before either testing out sections of the work or getting feedback from the developer/owner.  It would be a real challenge is we finished the whole house only to discover that we didn’t correctly install the plumbing…!!

#ea872 #foundations #ea