I jumped ahead on this week’s readings as the two articles presented were extremely relevant to what I’m going through today in my organization.  I will admit, I went from one Gartner article the last semester, harping on the importance of spending time analyzing the current state of an organization’s EA, to another Gartner article imploring an organization not spend time on the current state of their EA.

However, I have come to learn that Enterprise Architecture is truly about what is needed, based on current constraints, for an organization to change and flourish.  The only way to find out what an organization needs, is to attempt to map out what is currently in use or progress.  Burke, B., Papegaaij, B., Guevara, D., (2011) assume that “Focusing on the current state positions EA teams as inhibitors to change rather than change agents.”  This statement describes the aftermath of steps my business unit has taken to understand our new processes for a better EA structure.  From baselining our software development cycle to designing a new communication plan based on our findings, we have been met with much resistance.

The four teams that interact the most when you think of SaaS are Product, IT (development), UX, and Design.  With all teams assigned the same vision and goals, our approaches to executing said goals are vastly divergent.  It is not the experience our team lacks, but the will to collaborate and create an all-encompassing EA strategy.  I walked around my office and asked one person from each team to articulate what they felt was the most important piece in uncovering our EA of the future.

Product – “be the partner of choice for our hotels to utilize our software while extending our capabilities to other products; lead the market in consumer-centric features that change the industry”

Development – “capitalize on reusable components and remain agile with management/executive requests; avoid being pigeon-holed into deliverables and 100% feature completion, we may want to develop a piece of functionality that will benefit the enterprise as opposed to developing the entire feature and the benefit is only reaped by some”

UX
– “determine the best way to make the most valuable product for the users AND the business; what makes money for our company; and what is the most sustainable (portable, expandable, scalable)”

Design
– “build a framework for a scalable implementation of a product’s design; be a part of the solution when UX and product receive business requirements”

As you can see above, the future state of EA can be articulated by our departments; no issues there.  Our downfall has been spending too much time on the current state of EA and taking inventory, rather than proactively marrying the above visions into a viable strategy.  We are working on more core or basic competencies regarding streamlining, communication, knowledge management, and data sharing.  I foresee our training giving us more tools we need to become a “successful EA team” and it is only a matter of time for our execution to be semi-flawless!

References:
Burke, B., Papegaaij, B., Guevara, D., (2011, January 11) Enterprise Architecture Program Pitfalls: Don’t Start With the Current State. (ID Number: G00210232). Gartner Database.

Ross, J., Weill, P., Robertson, D. (2006).  Enterprise Architecture as Strategy.  Creating a Foundation for Business Execution, Ch, 5.

Advertisements