The document summarizes a management development program for directors of archives that took place from 2006 to 2010. Over 75 organizations participated in modules that taught an "outside in" approach to strategic leadership and an enterprise architecture framework. Participants developed draft blueprints for their organization's enterprise architecture and learned from peer-to-peer exchange and examples from other industries. Key learnings included that an outside perspective is valuable, archives must adapt to competition, and frameworks and peer learning can facilitate organizational change.
Strategic leadership and management development for archives
1. Strategic Leadership for the Archive of the Future Management Development Program 2006 - 2010 Drs. René R Tol, Yuj Advies bv The Netherlands Institute for Heritage and De Baak (management center VNO/NCW)
2.
3.
4. Building a house analogy: the four views Why do I want a new house? Business view Functional view What should the new house give me? Technical view With what will the house be built? Implementation view How will the house be built?
5. Architecture: Three Roles Customer Architect Contractor Form Function Durability Regulation Constructionprinciples Drivers Principles Model Standards
7. EA Framework: An example Survey customers Train resources Use Microsoft based commerce systems “ Ramp-up” time is reduced Will have to partner to acquire needed expertise Limited skill set Implementation view Business view Research db products Technical view Compatibility, integration issues Need to develop or outsource Customer must check inventory, make valid orders Use scripts, database to check inventory and validity Customers browse, check inventory, order, pay without help Needed for e-commerce Requires 24 X 7 system availability No resources for 24X7 support Functional view Investigate partners Goal: Improve time-to- marke t Develop e-commerce capability Reduces order processing time Needs modifications to IT infrastructure Beyond year’s budget Driver: Competition is outstripping us on delivery
Architecture analogy: building a house After you decide to build your own house, whom do you contact first? Do you go to the bricklayer, or the interior decorator, or the kitchen-supplier? No, of course not. You go to someone with whom you can discuss all the key ingredients, someone who can help you to look at this project from all sides in a coherent way, someone who can determine the necessary steps to be taken. You go to someone who helps you to build and maintain an integral picture of what you want to achieve, a picture that helps you to make your decisions and to communicate with all the different parties involved. In short, you go to an architect. How does the architect help you? He or she builds a high-level picture, a concept of the house in its environment, based on questions that you have to answer. The architect knows what questions to ask and how to organize the answers to those questions. We call this high-level picture architecture. It will be organized in different views, representing major aspects of the house. Each view can be divided into subviews to create the architectural concept. Both building architecture and information system architecture must address specific needs that answer the questions why, what, how, and with what. Each of these questions addresses a different “view.” Whether you are building a house or an information architecture, an architect can help you build and maintain an integral picture of what you want to achieve, a picture that helps you to make your decisions and to communicate with all the different parties involved. The building or information systems architect helps you by spending time with you to understand your needs and desires. Then he/she builds a high-level picture, a conceptual model or sketch of the house in its environment. Ask yourself this question: Is it the RIGHT SOLUTION for the client?
Each view feeds the next view or a later view: The principles or drivers from one view form the rationale for the principles in the next or subsequent view. Each principle must be based on some reason or rationale already stated. In the technical view, some principles may be IT constraints. The rationale is a form of “derived from” statement. The implications and obstacles from one view provide the input for developing the principles for the next (or later) view. The implication or obstacle must be recognized in the next (or later) view or there is no point in having them. The implication/obstacle is an impact statement. Tracing the sources of principles or requirements provides a means for understanding the impact of proposed changes. A forward and backward link to principles helps in the tracing. Actions are linked to the implications and obstacles that they address.