Showing posts with label Compliance. Show all posts
Showing posts with label Compliance. Show all posts

January 22, 2010

Checklists: Safety Nets or Strangleholds

Many functions in government are guided, if not driven by checklists. For example, federal information technology management has many checklists for enterprise architecture reviews, capital planning and investment control, IT acquisition reviews, configuration management, systems development life cycle, IT security (FISMA), Privacy, Section 508, and more.

One of the frequent criticisms is that these functions are just compliance-based and are not focused on the real-world task at hand—whether it be planning, governing, executing, servicing, securing, and so on. For example, many have said that FISMA needs to be amended, because our IT security staffs are so busy with their compliance checklists and reports that they are not adequately focused on strategically or operationally securing the enterprise from attack. Similarly, EA review boards have been criticized for being an almost thoughtless checklist of architecture alignment to the FEA and not of real planning value.

Yet, inherently we know that checklists are valuable and that is why they have been so heavily mandated and incorporated into our processes. Without the checklists, we know from past experiences with failed IT projects, poor IT investment decisions, and security issues that many of these could have been prevented if only we had thought to ask the right questions, and so these questions got codified—and we learned from some of our mistakes.

With regard to this, there was a fascinating book review in the Wall Street Journal on a book called “The Checklist Manifesto” by Atul Gawande.

The author:

Mr. Gawande makes the case that checklists, plain and simple, save lives and we need them. He cites examples of “how stupid mistakes in surgery can be largely eliminated through pre-operative checklists” and how “checklists first became the norm in aviation, where pilots found that minor oversights in sophisticated planes led to tragic crashes.”

Overall, the book’s author maintains that “checklists seem to be able to defend everyone, even the experienced against failure in many more tasks than we realized. They provide a kind of cognitive net. They catch mental flaws.”

The reviewer:

The reviewer points out the important flip side to checklists as follows: “Bureaucracy is nothing but checklists. That’s part of what’s wrong with government—officials go through the day with their heads in a rulebook, dutifully complying with whatever the lists require instead of thinking about what makes sense.”

The reviewer makes the point that someone in authority needs to use judgment and that means: “relying on individual creativity and improvisation—the opposite of a checklist.”

The review goes on to then try and address the seeming contradiction between the need and value of checklists and the stifling effect that it can have by pointing out that “The utility of formal protocols [i.e. checklists, standard operating procedures (SOPs), etc.] varies with the nature of the activity—some activities are highly systematized, like engineering and other dependent on the judgment and personality of the individual. Spontaneity and imagination are important in many jobs.”

So there you have it—checklists—are helpful in defined, routine, almost mechanized areas where we can identify and itemize the necessary tasks, they are common to its performance, and they are proven to help avoid frequent oversights and mistakes. But where agility and innovation is called for, checklists can lead to either bureaucracy and/or missing the mark in getting the job done.

So are checklists helpful or hurtful with technology?

On one hand, technology is a fast-changing, innovative field that drives organizational transformation and thus it cannot primarily be a checklist function. Technology requires visionary leaders, talented managers, and customer-driven staffs. There isn’t a checklist in the world can inspire people, build meaningful customer relationships, and solve evolving, large and complex business problems.

On the other hand, there are common IT operational functions that need to get done and well-known pitfalls, and for these areas checklists can help us not make the same dumb mistakes again and again. For example, we can check that we are not making redundant IT investments. We can verify that appropriate accessibility for the handicapped has been provided for. We can safeguard people’s privacy with appropriate assessments.

The place for checklists in IT is pretty clear:

· STRANGLEHOLDS—Checklists cannot be a stranglehold on our business performance. They are not a substitute for thinking and doing. They cannot replace dedicated, talented, hardworking people addressing challenging and evolving business requirements with new and improved processes and technologies.

· SAFETY NETS—Checklists are safety nets. They are codified best practices and lessons learned that help us in not making routine, yet costly mistakes again.


Share/Save/Bookmark

July 12, 2009

Information Management Framework

The Information Management Framework (IMF) provides a holistic view of the categories and components of effective information architecture.

These categories include the following:

Information-sharing--Enable information sharing by ensuring that information is visible, accessible, understandable, and interoperable throughout the enterprise and with external partners.

Efficiency--Improve mission efficiency by ensuring that information is requirements-based, non-duplicative, timely, and trusted.

Quality--Promote information quality, making certain that information provided to users is valid, consistent, and comprehensive.

Compliance--Achieve compliance with legislation and policy providing for privacy, freedom of information, and records management.

Security-- Protect information assets and ensure their confidentiality, integrity, and availability.

All areas of the framework must be managed as part of effective information architecture.

Share/Save/Bookmark

May 28, 2008

Blogs and Enterprise Architecture

Well this is interesting to write: a blog about blogging ;-)

Blogs are becoming a great new tool for enterprise communications and an alternate to clogging up already full email boxes.

CIO Magazine, 15 January 2008, states that “enterprise users can get lost in storms of ‘reply-all’ e-mails while trying to manage projects. Blogs offer a better way.”

The group president of systems and technology for Bell Canada says that “email, used by itself just doesn’t cut it anymore for project management and interoffice communication.”

What’s the interest level and use of blogs?

Forester Research reports that “54% of IT decision makers expressed interest in blogs. Of companies that had piloted or implemented blogs, nearly two-thirds (63%) said they used them for internal communications. Fifty percent said they used blogs for internal knowledge management—and these companies are leading the way of the future.”

A software social consultant says that “traditional enterprise solutions were designed to keep IT happy. They’ve not usually designed with any thought to the user, like a blog is.” What a nice user-centric EA concept, design technical solutions that meet user requirements; let business drive technology, rather than doing technology for technology’s sake.

Why do people resist blogs?

“People are hung up on this concept of the blog as a diary and as an external marketing medium,” rather than understanding its criticality as a tool for communications and knowledge management.

How can you advance the use of blogs in your organization?

  1. Calming the troops─if people are nervous about blogs, consider avoiding the term blog and call it an ideaboard or some other non-technical and non-threatening name.
  2. Security and compliance—build the blog behind the corporate firewall and “establish rules of engagement,” so that proper social and legal etiquette is not violated and passive-aggressive behavior or “web rage” is mitigated.
  3. Start small—“blogs catch on virally, when you need to introduce the idea to the right test group, which will evangelize the idea to the rest of the enterprise.”
  4. Tagging—have people “tag their posts with keywords that will help later with search and discovery needs.”
From an EA perspective, blogs are not a substitute for email; we need email (some of us desperately, like a morning cup of joe), but blogs are a great complementary tool for participatory communications that involve discussion type interaction by more than two users or for capturing enterprise knowledge and making it available for discovery. Also, blogs are a tool that gives a voice to people, who may otherwise remain part of the silent masses; people feel freer to express themselves in blogs, and through freedom of expression comes advancement of ideas, greater buy-in, and better enterprise decision-making.


Share/Save/Bookmark

May 6, 2008

Information Management and Enterprise Architecture

Information management is the key to any enterprise architecture.

Information is the nexus between the business and technical components of the EA:

  • On one hand, we have the performance requirements and the business processes to achieve those.
  • On the other hand, we have systems and technologies.
  • In between is the information.

Information is required by the business to perform its functions and activities and it is served up by the systems and technologies that capture, process, transmit, store, and retrieve it for use by the business. (The information perspective is sandwiched in between the business and the services/technology perspectives.)

Recently, I synthesized a best practice for information management. This involves key values, goals for these, and underlying objectives. The values and objectives include the following:

  1. Sharing –making information visible, understandable, and accessible.
  2. Quality—information needs to be valid, consistent, and comprehensive.
  3. Efficiency—information should be requirement-based (mission-driven), non-duplicative, timely, and delivered in a financially sound way.
  4. Security—information must be assured in terms of confidentiality, integrity, and availability.
  5. Compliance—information has to comply with requirements for privacy, Freedom of Information Act (FOIA), and records management.

The importance of information management to enterprise architecture was recently addressed in DM Review Magazine, May 2008. The magazine reports that in developing an architecture, you need to focus on the information requirements and managing these first and foremost!

“You need to first understand and agree on the information architecture that your business needs. Then determine the data you need, the condition of that data and what you need to do to cleanse, conform, and transform that data into business transformation.”

Only after you fully understand your information requirements, do you move on to develop technology solutions.

“Next, determine what technologies (not products) are required by the information and data architectures. Finally, almost as an afterthought, evaluate and select products.” [I don’t agree with the distinction between technologies and products, but I do agree that you first need your information requirements.]

Remember, business drives technology—and this is done through information requirements—rather than doing technology for technology’s sake.

“Let me also suggest …Do not chase the latest and greatest if your incumbent products can get the job done.”

In enterprise architecture, the customer/end-user is king and the information requirements are their edicts.


Share/Save/Bookmark

February 18, 2008

Leadership, Change, and Enterprise Architecture

Enterprise architecture is about planning, managing, and measuring change in an organization. To effect change requires true leadership, and this requires multiple skills.

In the book, The Leadership Triad by Dale Zand, three essential forces of leadership are presented—knowledge, trust, and power. These leadership forces guide constructive organizational change.

“Like three horses pulling a chariot, these forces, if coordinated and working together, provide a swift and exhilarating ride. But if one force is mismanaged or pulls against the others, the ride is bumpy and can end in disaster.”

Effective leaders integrate the three forces of knowledge, trust, and power to drive effective change and maintain efficient operations in their organizations: “They know what should be done, they have the trust of their people, and they use power appropriately:

  1. Knowledge—“leaders know or can find out what should be done…they have vision and they know how to fulfill that vision. They set clear, challenging goals, and they know what needs to be done to reach the goals…they know how to gain access to the knowledge of others, and they know how to work with people to convert that knowledge into action.”
  2. Trust—“people trust effective...leaders, giving them loyalty and commitment… [They] earn trust by disclosing relevant information, sharing influence, and competently using knowledge. They earn trust by fairness in their dealings with others—fulfilling the spirit of their agreements, sharing rewards and hard times and not abusing their power.”
  3. Power—“leaders use their power appropriately. They know how to be directive or to delegate. They know how to review and evaluate constructively. They know how to be consultants, providing guidance rather than issuing commands.”

Why not just lead in a command and control fashion like in the military or law enforcement organization?

“The heroic fantasy of one person at the head of a column and followers shouting ‘charge’ as they mount the battlements is outdated. Instead leaders need to learn to use the sensing, searching, and thinking ability of all people within the organization.”

How are these leadership skills similar to those necessary for implementing enterprise architecture?

Knowledge, trust, and power are the cornerstones of an enterprise architecture program.

1. EA makes information transparent and provides information products to distribute knowledge and enable better decision-making. EA information is critical to decision-making, particularly in terms of ensuring sound IT investment management decisions, IT planning, analysis of problem areas—uncovering gaps, redundancies, inefficiencies, and opportunities--driving business process improvement, reengineering, and the introduction of new technologies to the organization.

“In the twentieth century society crossed…into the information age, marked by the emergence of the knowledge organization.”

“Competitive advantage in the information age is in constant jeopardy—knowledge is fluid, and creative thinkers leapfrog over existing knowledge.”

“Knowledge travels with the speed of thought, but can be blocked by the smallest emotional barrier. It can enlighten the entire organization’s operation, yet it can easily be concealed if people do not want leaders to see it. People throughout organizations continually acquire and create important, critical knowledge about customers, [suppliers], products, technology, costs, and competitors. But that knowledge can remain hidden and inaccessible to leaders. In the new world leaders need to liberate knowledge and creative thinking at all levels and in all corners of the organization. To compete, leaders need to move knowledge from where it is to where it can be used to define and achieve appropriate goals.”

EA helps to synthesize information and liberate knowledge to meet strategic goals.

2. EA is based on the trust of business and technical leaders and staff across the enterprise. EA synthesizes business and technology information. It relies on the trust of divisions, departments, and subject matter experts (SMEs) throughout the organization to share (and not hoard) information and build a results-driven, process-oriented, interoperable, standardized, cost-effective organization, rather than a siloed, ineffective one. In an EA-directed organization, siloed functions and management relinquish their own personal interests and perhaps, selfish motives and instead plan for the good of the overall organization. For example, decisions on IT investments are made based on enterprise priorities and cost-benefit-risk-architecture considerations, rather than who has the money to spend.

“Trust regulates the disclosure of information—how open people are with relevant information…trust regulates mutual influence—how receptive people are to each other’s goals and concerns, and trust regulates control—the intention to fulfill the spirit of a decision and willingness to rely on another person to implement her part of the decision.”

“Mistrust causes people to censor, delay, and distort relevant information. Social uncertainty compounds ambiguity, masks difficulties and deprives leaders of the opportunity to make high-quality decisions

3. The EA Board (chaired by the chief enterprise architect) ensures that proposed new IT projects, products, and standards align to and comply with the enterprise architecture. EA must have the power to mandate and enforce alignment and compliance or else the target architecture and transition plan is just a sham that will not yield enterprise results and achieve stated goals. Additionally, EA must have the ability to require SMEs to contribute regularly to the development, maintenance, and use of the EA. The business and technical SMEs are the owners of the EA content and must be partners with the EA team in ensuring that the architecture is kept current, accurate, and complete.

“Power is the ability to influence others so that they do or do not do something.”

“Leaders have legitimate power to determine the process by which decisions will be made.”

Knowledge, trust, and power are three dimensions of leadership that are the foundation for an effective EA program. EA ensures that the information needs of the organization are met in terms of business and technical baseline and target architectures and transition plans. EA relies on the trust of its organizational partners in the business and technical domains to share information and adhere to architectural decision and standards that are in the best interests of the overall organization, rather than any one individual, group, or function. And finally, EA requires the power to ensure alignment to and compliance with the architecture and the decisions of the architecture board or else EA is just a paper tiger and will fail.


Share/Save/Bookmark