EA 872 Week7: Data Stewardship

Data Stewardship is an essential part of any organization and should be included in the future state architecture activities. This is of significant importance since we are at an age where it is all about the data. We are in a continuous raging momentum of digital transformation of all businesses across all industries. This is giving data teams a greater leverage and visibility within the enterprise hence the importance of mapping architectural principles to data stewardship and engaging EA team accordingly.

Having an effective data stewardship is a guarantee for the quality and integrity of one of the most vital assets of the enterprise: the data. Data cycles such as generating, acquiring, managing, enriching, maintaining,migrating, and disposing of if any, are both business as well as IT shared responsibility with collaborated governance. EA can facilitate the discussions,lead and guide both parties on producing a reference mapping matrix to the architecture principles of the enterprise. To facilitate this exercise, the EA team should start with standard templates such as the Gartner toolkit which categorizes the data stewardship requirements into three. First is definition and scope covering topics such as the authoritative information source, the audit-able system, single storage. The second is the processes, responsibilities and usage of data listing responsibilities for enforcement, system of records, standards, data repository for analytics, etc…. The third category covers data integrity and system security including the data as an asset, disaster recovery, internal and external security, encryption, and authorization. 

Starting with these broad data stewardship requirements, an EA team can come up with a template to use in discussion with stakeholders and IT to map to the architecture principles thus completing another important artifact as part of the future-state architecture implementation activities.

References:

"Data Stewardship Is Everybody’s Business: Best Practices for Data Quality Management". Rado Kotorov (insights.wired.com,  July 21, 2014) 

"L04: Future-State Architecture: Implementation Level". Retrieved from Penn State EA-872 class material.

EA 872 Week6: Building the Future-Sate Architecture

During EA initiatives, one of most important steps is building the future-state architecture. Yet, this is also a hard step to achieve and involves lots of discussions, different meetings, and distilling the different ideas and requirements into some very important artifacts that need to be built. These artifacts typically describe the desired future state of the enterprise and include requirements of the business needs, principles to reference decisions of the architecture, and models on how the components of the EA will interact to deliver the business value.

EA team has to lead the development of the conceptual principles for the business, information and technology viewpoints pertaining to the enterprise. This is not an easy task as the core EA team has to take the high level architecture principles taken from the business team discussions w.r.t to the business context of the enterprise, then  engage in detail the implementation team (solutions),  technology team , and the EA governance team to derive suitable matrices that can be referenced to guide the decisions made  during the architecture implementation.  An output example would be mapping business architecture principles such as compliance to an information principle such as access to data, or mapping updates and modifications to data to the auditing capability.  Additionally, the same compliance example would be mapped to technology principles such as master data management of all data (ex. an MDD system applied to the data repository).

Conceptual process pattern is another artifact of the business viewpoint of the enterprise architecture that needs to be delivered. This is a diagram depicting the detailed level business process patterns that are necessary to support the enterprise business strategy. This diagram can be derived following discussions with the executive team, VPs, and architecture team  (information and business).

A process topology diagram is an artifact that shows how all critical processes of the enterprise follow the business functions and relate to the business anchor model chosen by the enterprise. It might take time and cycles of drafting and modifications, but the process topology diagram will provide a visual depiction of the strategic intent of the enterprise and business change requirements that helps as a reference and simply from a visual point to drive clarity on direction. 

An important element of what runs in each enterprise artery system is information. This is why an information flow diagram showing how information is consumed including the different attributes of the business is another important EA artifact. These diagrams can get tricky if there are too much flow-arrows on the diagrams and it might be helpful to track the details in separate flow diagrams for each unit while keeping the master information flow diagram at a higher level.

Another artifact is the application layer diagram that shows how all the enterprise different units can be consolidated including the future strategic view. This can also be supplemented by additional vertical hierarchy diagrams showing the applications domains and infrastructure domains and horizontal domains within each such as the application tools, application server, integration, database, storage etc… 

In summary, building the future-state architecture is probably one of the most consuming efforts as viewpoints need to be solidified and the enterprise requirements and capabilities need to be mapped out from the existing current state. It is recommended not to spend too much time documenting the current state and rather spend the time focusing on building the future-state architecture by delivering artifacts such as the above mentioned ones.



References: 

"L04: Future-State Architecture: Implementation Level". Retrieved from Penn State EA-872 class material.

"Enterprise Architecture Program Pitfalls: Don't Start With the Current State". Brian Burke, Bard Papegaaij, Dave Guevara. (Gartner, Jan 2011)

EA 872 Week5: EA and The Good to Great

It has been a while since I have felt the urge to read a book. I mean an actual physical book. I am so immersed in online activities and reading summarized articles that it just seems to be a more efficient way to acquire knowledge and read topics, trends and pearls of wisdom. However, when “Good to Great”* was brought up in last class discussion, I couldn’t help but get curious about it and where its content and ideas might sit with respect to EA practices if any at all.

In this book, the writer, Jim Collins with the help of the research team, identifies companies that were able to progress from the good to the great state and sustaining that state for a considerable time.  The process thoroughly combs the list, classifies companies, and finds out the foundations of what is needed or rather the characteristics  of a company that went from a good to a great level. Its interesting approach on analyzing the data and within what context, the companies themselves across different industries, the long period of time chosen for the study of a company, and cross matching different qualification criteria is definitely a well researched project promising the results to be detailed and indicative. I do have some comments on how the last five to ten years and the change in the continuum of social, mobile and internet might have affected the results and if any change to the criteria but I will leave that to another day. Today, I’m going to focus on what is identified as Level 5 Leadership in the book and how that might relate to what EA is about and why EA is important within this topic.

Level 5 Leadership is defined around a set of characteristics  including being a catalyst for transition, leading, setting standards, building for next success in the next generation and more. These basically define the executive who can take an enterprise to an enduring greatness level through a mix of professional will and personal humility. The idea that disciplined people, disciplined thought, and disciplined action within a flywheel from buildup to breakthrough to achieve greatness is a solid one. Extrapolating some of these finding to EA, one can find similar ideals and can draw a conclusion of why EA must be part of that flywheel process and a facilitator or a tool among many for the Level 5 Executive to use in making that transition from good to great. I will pick few examples. Consider setting up successors for even greater success. EA is all about building capabilities to facilitate the transition from current state to future state to achieve the goals and objectives of the leadership. This is neutral to who is managing the enterprise and it standardizes  the assets and strategies for continuing to build on success. Another one is diligence. It is important in EA to have a diligence and thorough approach to understanding the intricacies of the organization or enterprise, documenting the different requirements, artifacts, assets, business processes, key components and much more. Anyone who has been involved in EA whether it be the discussion with business and IT or building a repository of components and artifacts knows how much important it is to be diligent and detailed for the EA intuitive and practice to be successful. Same thing can be said about having standards and abiding by them. Last but not least, I like the mentioning of the tendency of Board of Directors to usually select famous or celebrity leaders from the business fabric rather than focusing on the needed character for the leadership level. This is a reminder of the countless scenarios where different LOBs within the same organization tend to go out and try to buy solutions for there specific business problems based on the dazzling effect of the new product(s) rather than consulting and having EA to build a solid assessment of the needs of the LOB to compare to the repository of existing solutions and software within the organization or the corporate software choice for that particular need. 

Back to my comment on how the last five to ten years might have effected any of the conclusions of the book, the one thing that is certain is that the dynamics of running a great company or getting a company from good to great are becoming more and more a challenging issue for executives and leadership. Reading the referenced book affirms my belief that EA is yet another important tool that is a must-have within a Level 5 type of leadership as well as a catalyst to getting to the future great state of the goals and objectives set by leadership.

References:  

 * Jim Collins (2001). Good to Great. HarperCollins Publishers Inc.

EA 872 Week4: The Importance of an EA Core Diagram

This week I would like to address the importance of core diagrams in an EA initiative. I have always been an advocate of white boarding or using diagrams to clarify concepts and relaying information in an easy and simple manner. This is especially important and helpful when one has a room full of participants from different business backgrounds and both technical skills and business acumen are not the same across the room. EA is no stranger to those meetings and situations where typically business and IT converge to come up with vision and decisions on future state of the organization.

To facilitate discussions and ensure governance, EA core diagrams showing the business processes, infrastructure, integration and standardization requirements of the adopted operating model of the company can and should play an important role.

This conviction stems from the fact that core diagrams and references help clarify the difference between EA and IT Architecture. EA core diagrams are conceived by addressing the high-level business processes and IT requirements for the organization operating model. Excluding technical information that span second and third detailed levels helps keep a concise focused message and great conversation catalyst by elevating the items of discussion to the core of how business operates and what is needed from IT to support that model.  This helps and comforts business who is used to seeing typical IT diagrams that don’t necessarily correlate immediately to processes and daily operating concepts with too much emphasis on standards, tech syntax, and descriptions. At the same time, while going through the process of completing the EA core diagrams, non IT resources can focus on transferring business domain knowledge and sort of educate IT on the operating model. This way, when IT attempts to come up with detailed architecture and application diagrams, the whole organization can avoid the typical scenarios of having non realistic or too much “ivory” looking documents and diagrams that are of no use. Having a shared EA core diagram helps both parties to understand and agree on the organization’s enterprise architecture. 

This is why encapsulating EA in a core diagram describing the operating model is a well worthy exercise in the initial conversations and meetings between business and IT. It is very helpful to have a simple one pager picture or diagram at a high level that is used to capture the business process, the shared data ,and the technologies which are all important part of the foundation for execution during EA initiatives. Typically, such core diagrams would include the important common elements such as: core business process, shared data driving core processes, key linking and automation technologies, and key customers. These  are highlighted  since it is crucial to have a clear idea of the chosen operating model elements and collaborate on the essentials and basic pillars of the business for the best approach to capturing current state and how to move to the desired future state. There are many basic templates available that can be leveraged to capture this information for any of the typical operating models such as unification, diversification, coordination and replication.  Keeping in mind that “Choosing an operating model forces a decision on a general vision”*, an EA core diagram complements this statement by showcasing that senior management needs to be involved in  the early EA discussion and approve the core diagram along with IT.  It is understandable that the first run over core diagrams will be tough exercise but as progress is achieved and the diagram gets completed,  everyone in the organization will realize the importance of having  it  and will be the reference for any future conversations or decisions to be made.  The core diagrams also encourage healthy debates early in the conversations, help to shake legacy thought,  and stir movement in the right direction that best serves strategic goals and objective of the future state desired. They are best at showing EA as the enabler of business objective by providing a common customer view, unified shared information, governance, redundancy reduction, and steering the production of new applications that convey to the desired operating model.

References:  

* Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, Mass.: Harvard Business School Press.