Now that Enterprise Architecture has run its course to establish enterprise standards, the struggle has been to get effective use from them. Many public sector organizations are moving beyond the build stage of EA representations to establish services for continuous enablement of business needs. After all, while documentation took place, the enterprise had often moved on to many changes that have never been captured.
Using the historical representations may be somewhat effective, but limiting the business to what has historically been implemented would categorically deny enabling the business in some cases. The move is commonly referred to as Agile EA. McKinsey refers to this as perpetual evolution. The bottom line is the key to services as living with business organizations trying to enable their business needs while maintaining compliance where appropriate, and innovating where necessary to create new standards to enable what is essential to support change. In this Blog, we would like to encourage public sector organizations to add their examples of Agile EA, Perpetual Evolution, or Progressive Elaboration – what you call it won’t matter since the services are clearly helping the business achieve what it needs to achieve.
We, too, hope to introduce new techniques on a regular basis to incorporate into enterprise EA services. Here is an initial technique:
Business Procurement Services: If it is so true that enterprise architecture must start with business needs, then why is it so hard to actually listen to the business to understand, at a strategic level, what they need to excel at their mission? Perhaps the business architecture domain is not as easy to define as the EA community believes it is. After all, business leaders and their staff have to run the business as effectively and efficiently as they can, and don’t have the time to understand topics like Enterprise Architecture. Rather than trying to force business people into understanding EA, a better method is to provide services that help take them through the steps required to procure new systems that enable business operations to the level required.
The next level of growth for most Information Technology organizations in the public sector is to become the consulting arm for the enterprise. Where today, they are all too distant and unfamiliar with how the business operates and what they need to achieve; trying to enforce compliance with an EA that is not well understood is futile. Take the step to build business architect capabilities by investing with the business to define the business architecture needed to procure not only a needed solution, but one that sets a new standard for EA in some ways and in other ways is compliant. There are a few key practices that are essential to help build the “consultant” style operations to provide these services to the business:
- Learn how to listen. When any organization feels like they are being dictated to, they will not be responsive to your help. Listen and feedback information that can demonstrate you understand what the business is saying they need. Avoid throwing out any solutions as the only way to go since it is “a standard in this enterprise.” You could end up with the same solution, but by clarifying the needs sufficiently, you could surprise yourself in finding even better solutions for the enterprise.
- Be Agile. Agile begins with stories – stories of the business. Begin this conversation and you will find that there can be a vision for what expert mission services would look like and how they could be carried out. Some organizations document this in a “concept of operations.” It is not important to be formal with the definition of this document that captures what the business needs. Concentrate on tuning your understanding to the point where the business agrees (strongly) with what is being expressed. Most procurement approval documentation will flow from this information. It will need to represent goals, objectives, outcomes, and the relationships in the environment necessary to achieve the outcomes through operations.
- Iterate on alternatives. Try to encourage thinking that allows many viewpoints to be considered. How does each alternative solution provide the data and information necessary for appropriate decision making and closure? How does each alternative solution establish a sustainable maintenance and operations profile? How much training and support is required for initial and ongoing operations? Do the solutions support work the way that the business has to operate in today’s world (mobile, etc.)? Is the solution secure? Answers to these questions will either set new standards or follow in line with current standards in the EA. Focus on enablement, not compliance, since compliance will hold the enterprise back.
- Service builds trust. Continue to serve the business in ways that gets them through procurement activity and establishes systems that truly do improve operations the way they have defined them. The trust built from this perspective will gradually help the business listen also to some ways in which they could adjust to standards with little or no variance from desired capability. Don’t take advantage of the trust – this is what has caused such a divide between the business and IT for years. You have to start all over again at learning how to listen if you violate this tenet.
Enjoy the system and solution possibilities and innovation possible with Agile methods to adapt the EA to what the business needs.