Life Expectancy and Enterprise Architecture

We all hope and pray for a long and healthy life with our loved ones. Unfortunately, when serious illness strikes, the question is how long does a person have to live?

The Wall Street Journal, 6 June 2007, reports that despite all the diagnostic medical tools today, predicting life expectancy is still “a very inexact science.”

While it does not seem odd to me that “doctors often fumble predicting life expectancy” since this is truly only something G-d can know for sure—what is odd is the magnitude of the discrepancy with doctors predictions. “Doctors overestimated dying patients’ survival by a factor of 5.3”!

Why the gross inaccuracy? And can this provide any lessons for enterprise architecture planning?

• Forecasting is not a science—“Even some of the best scientific studies of some of the more common medical cases points to one conclusion: we don’t really know.” Similarly, with planning business and technology, we can’t really see into the future or around corners. The best we can do is to extrapolate from events and trends. This is more an art than a science.
• Old/bad data is a poor basis for planning—“Life expectancy data for such patients are dated. ‘True life expectancy with best treatment is constantly changing.’” Similarly, with business and IT planning, events on the ground are constantly changing, so for planning to be even somewhat accurate, you need real time and quality data.
• Optimism is an exaggeration—Doctors tend to be overoptimistic with their life expectancy predictions, “in part because they tend to be confident in their abilities and hopeful for their patients.” While we can’t give up hope—ever—we should not be overconfident in our abilities. When architecting the organizing, we must try to be as realistic as we can and not look at the enterprise with rose colored lenses.
• Overlooking the obvious—“Doctors simply overlook the signs of nearing death.” As architects, we cannot overlook anything. We need to be on the lookout for the latest business and technology trends and plan accordingly for the enterprise.
• Difficulty communicating bad news—“The pain and difficulty of communicating the prediction exacerbates the error…when estimating life expectancy for patients who, it turned out, had about a month to live, doctors tacked on 15 days onto their private predictions.” Enterprise architects need to be good—no expert—communicators. This is important in translating business-technology speak and in charting a course. If the current roadmap is not right for the organization, architects need to articulate the problems, why and how to fix them.
• Treatment can cause more problems—“Patients and doctors expecting a longer survival time may agree on more invasive treatment, adding the burden of side effects and complications to patients in their final days.” Similarly, as architects, we may see a business process or technology problem and in trying to fix it, end up doing the wrong thing and exasperate the problem. So like doctors, our first pledge needs to be to do no harm.
• Feedback and quality control—these “could help hone survival estimates.” So to with planning and governance, doing the assessment/lessons learned and performance metrics can be very valuable for improving practices and processes going forward.

Life Expectancy and Enterprise Architecture

The Visionary and Enterprise Architecture

In User-centric EA, we develop a vision or target state for the organization. However, there are a number of paradoxes in developing an EA vision/target, which makes this goals quite challenging indeed.

In the book, The Visionary’s Handbook by Wacker and Taylor, the authors identify the paradoxes of developing a vision for the enterprise; here are some interesting ones to ponder:

1. Proving the vision—“The closer your vision gets to provable ‘truth,’ the more you are simply describing the present in the future tense.”
2. Competing today, yet planning for tomorrow—“By its very nature, the future destablizes the present. By its very natures, the present resists the future. To survive you need duality [i.e. living in two tenses, the present and the future], but people and companies by their very nature tend to resisting living in two tenses.” “You have to compete in the future dimension without destabilizing the competition [i.e. your ability to compete] in the present and without subverting the core values that have sustained your business in the past.”
3. Bigger needs to be smaller—“The bigger you are, the smaller you need to be….great size is great power, but great size is also stasis.”
4. The future is unpredictable—“Nothing will turn out exactly as it is supposed to…yet if you fail to act, you will cease to exist in any meaningful professional or business sense.”

So how does one develop a viable target architecture?

The key would seem to be in deconflicting past, present, and future. The past cannot be a hindrance to future change and transformation—the past must remain the past; lessons learned are welcome and desirable, but the options for the future should be open to innovation and hard work. The resistance of the present (to the future) must be mitigated by continuous communications and marketing; we must bring people along and provide leadership. The future is unknown, but trends and probabilities are possible for setting a way ahead; of course, the target needs to remain adaptable to changing conditions.

Certainly, any target architecture we develop is open to becoming a "target" for those who wish to take pot shots. But in an ever changing world and fierce global competition, we cannot sit idle. The architecture must lead the way for incremental and transformative change for the organization, all the while course correcting based on the evolving baseline and market conditions. EA is as much an art as it is a science, and the paradoxes of vision and planning need to be managed carefully.

The Visionary and Enterprise Architecture

Good to Great and Enterprise Architecture

What makes a good organization become great in terms of technology?

In the book, Good to Great by Jim Collins, the author describes a five year study conducted in organizational greatness and what makes a good enterprise become great. Here are some finding in terms of achieving technology success:

• Align technology with your mission—the key question that drives the enterprise’s technology is whether it fits directly with “what you are deeply passionate about…what you can be the best in the world at…[and] what drives your economic engine.”Through the User-centric EA target architecture, transition plan, and IT governance, EA moderates new investments in IT so they align with mission requirements and priorities.
• Technology enables mission execution—“Good-to-great companies used technology as an accelerator of momentum, not a creator of it…a company can’t remain a laggard and hope to be great, but technology by itself is never a primary cause of either of greatness or decline." User-centric EA synthesizes business and technology information to enhance decision-making. EA ensures that the organization’s technology direction and investments enable mission.
• Culture of discipline—Good-to-great companies have disciplined thought and action. They “respond with thoughtfulness and creativity, driven by a compulsion to turn unrealized potential into results; mediocre companies react and lurch, motivated by fear of being left behind." User-centric EA is a structured approach to managing and integrating business and technology. EA ensures that the organization follows an adaptable plan and does not get lurched around by the changing market, competition, or technology tides.
• Change incrementally—“‘crawl, walk, run’ can be a very effective approach, even during times of rapid and radical technological change.” User-centric EA develops the target and transition plan for the organization, which ensures an approach of incremental change. New IT investments and business process improvements are done in a phased approach, rather than trying to “eat the elephant in one bite.”

In short, User-centric EA is a perfect fit with the conclusions of Jim Collins research into good-to-great companies.

Good to Great and Enterprise Architecture

24 Hour Knowledge Factories and Enterprise Architecture

Enterprise Architecture is strategic information asset base that defines the business, information necessary to operate the business, technologies necessary to support the business operations, and transitional processes for implementing new technologies in response to the changing needs of business."

In the information economy we live in today, information is certainly an asset with expected returns for the numerous businesses in the services sector and the millions of people working as knowledge workers.

The Wall Street Journal in conjunction with MIT Sloan School of Management on 15 September 2007 reports that “today, we are witnessing the advent of the 24-hour knowledge factories…thanks to more robust information technology and a growing acceptance of offshoring, the concept is feasible.”The key to the organization being able to support 24 hour (round the clock) knowledge work is to have “an online repository of information accessible to all groups.”

What makes for a successful knowledge repository for sharing information between sites and teams?

• Acquisition— capturing all relevant knowledge that can support users knowledge work.
• Discovery—making data discoverable so it can be mined for those nuggets that can aid in job performance.
• Management—developing data standards including a common lexicon and metadata to deal with differences in semantics and formats.
• Dissemination—making the information accessible for standardized reporting or ad-hoc queries.

In User-centric EA, we are in the information business (providing information for planning and governance). And whether or not the information is needed 24.7, or during "regular" business hours, we need to develop information products, relate the data in useful ways, and make the information easy to understand and readily accessible to end-users. To do this, a robust EA knowledge center or repository is essential.

24 Hour Knowledge Factories and Enterprise Architecture

When the Plan Fails and Enterprise Architecture

Enterprise architecture develops the roadmap for the organization and no roadmap is foolproof. With any roadmap, sometimes there’s a traffic jam, an overturned tractor-trailer, or a washed-out bridge. Whatever the scenario, the EA plan is not the right way to go all the time, every time. That is why the plans need to be agile and responsive to the events as they unfold on the ground.

Similarly, in our personal lives, not every road we take is going to lead us to success. In business school we learn that 90% of new businesses fail within the first 5 years. Nowadays, even marriages fail at a rate close to 50%. And according to ExecuNet, the “average executive tenure is less than four years…[and] 18% of executives do not survive their first year in a new job.” So as individuals and as organizations, we can plan for success, but there are no guarantees.

Fortune Magazine, 9 June 2008, reports “a reversal or two can pave the way to triumph…[or] adversity makes you stronger.” Here’s how you can persevere in the face of adversity (adopted from Fortune, but my thoughts on what they mean):

1. Calculated risk taking—just because you or your organization fails at something, doesn’t mean it’s the end of the line. You have to pick yourself back up onto the proverbial horse and start riding again. It is risky to keep trying, of course. Life is full of risks. You can’t avoid risk. So you take calculated risks and keep trying until you succeed.
2. Get rid of the naysayers—doubters and naysayers can take the wind out of your plans and ambitions. Yes, listen to reason and experience and learn from it. But don’t just abandon your dreams. If you believe you can do something and can make a difference, you owe it to yourself to try.
3. Live a purpose-driven life—similar to an organization needing a mission, vision, strategy, and architecture to provide a purpose and roadmap for the organization, so to an individual needs a purpose and a plan to advance their personal goals and aspirations.
4. Visualize success—I’ve heard this one many times used successfully for those in sports, entertainment, going into interviews, and even those with illness and disabilities. You have to train your mind to think, feel, and actualize the success experience. If you can just visualize success, you are truly a step closer to it.
5. Lessons learned---We all make mistakes. It’s part of being human. The key though is to learn from those mistakes, so that you do better the next time around. Life’s lessons build on each other. That’s why with age comes wisdom. Experience can go a long way to a new round of success.
6. Failure is not a life sentence—While we may certainly feel that failure is the end of the world, more often than not, failure is temporary. We’ve got to see past the failure—see the light at the end of tunnel and make our way toward it. That light is success waiting for us.

In the end, we have to be strong to deal with the bumps and bruises we call life. I see enterprise architecture as a structure for dealing with risk and uncertainty. In its most simplistic form, identifying where you are, setting a target of where you want to go, and charting a course to get there is a lens that we can use in almost every aspect of our organizational and personal lives. Rather, than wandering along aimlessly, let’s set a path and try to have an interesting journey filled with learning, growth and hopefully some success for our efforts.

When the Plan Fails and Enterprise Architecture

Occam’s Razor and Enterprise Architecture

“Occam's razor (sometimes spelled Ockham's razor) is a principle attributed to the 14th-century English logician and Franciscan friar William of Ockham…The principle is often expressed in Latin as the lex parsimoniae (‘law of parsimony’ or ‘law of succinctness’)..This is often paraphrased as ‘All other things being equal, the simplest solution is the best.’… it is more often taken today as a heuristic maxim (rule of thumb) that advises economy, parsimony, or simplicity.’” (Wikipedia)

In Occam’s razor, “razor refers to the act of shaving away unnecessary assumptions to get to the simplest explanation.”

Thomas Aquinas made a similar argument in the 13th century: "If a thing can be done adequately by means of one, it is superfluous to do it by means of several; for we observe that nature does not employ two instruments where one suffices." (Pegis, A. C., translator (1945). Basic Writings of St. Thomas Aquinas. New York: Random House, 129.)

The principle of Occam’s razor is very applicable to enterprise architecture—how?

Occams razor is a call for simplicity, and this principle is a foundation for enterprise architecture in terms of consolidation, integration, and cost efficiency and takes specific form in terms of:

• Systems interoperability and component re-use
• Technology standardization and simplification

Paul O’Neill, the former Secretary of the Treasury was a true advocate of Occams razor and frequently asked “if not one, why not one?”

“The philosopher of science Elliott Sober once argued along the same lines as Popper, tying simplicity with ‘informativeness’: The simplest theory is the more informative one, in the sense that less information is required in order to answer one's questions.” (Wikipedia)

In this sense, Occam’s razor is a validation for User-centric Enterprise Architecture, which seeks to make information simpler, easier to understand, and generally more valuable and actionable to the end-user to enhance decision making. Moreover, Occam’s razor is also evident in User-centric EA application of principles of communication and design like simplifying complex information and maximizing use of information visualization in order to more effectively communication EA information.

Occams razor makes clear the need to transform from traditional EA’s development of “artifacts” that are often difficult for the user to understand and apply and instead develop more useful and usable information products and governance services.

Occam’s Razor and Enterprise Architecture

Eisenhower and Enterprise Architecture

Dwight David Eisenhower (October 14, 1890 – March 28, 1969), nicknamed "Ike", was a five-star General in the United States Army and U.S. politician, who served as the thirty-fourth President of the United States (1953–1961). During the Second World War, he served as Supreme Commander of the Allied forces in Europe, with responsibility for planning and supervising the successful invasion of France and Germany in 1944-45. In 1951, he became the first supreme commander of NATO. As a Republican, he was elected the 34th U.S. President, serving for two terms. As president, he oversaw the cease-fire of the Korean War, kept up the pressure on the Soviet Union during the Cold War…” (Wikipedia)

Dwight D. Eisenhower said that “in preparing for battle I have always found that plans are useless, but planning is indispensable.”

What does this mean when it comes to User-centric EA and target architecture and transition plans?

1. Plans are agile—you can plan, but you can’t control the situation on the ground. Therefore, EA plans are by definition undependable. A plan developed for one situation may be completely useless or actually counterproductive in another set of circumstances. Further, there are essentially infinite factors in every scenario and you can’t plan for every combination and permutation. Therefore, you can never really plan effectively, since in some aspects, the plan will always be off.
2. Planning is a learning process—while a specific EA plan itself may ultimately be useless, the planning process itself is extremely valuable. Bringing subject matter experts and stakeholders together to brainstorm, evaluate various scenarios, analyze alternatives, and “hash it out” helps everyone involved to understand the objectives, the battleground, the force structure (assets), and unify everyone around a common way ahead. This is the true value of planning.

In the end, EA plans must be agile and adaptable to the specific situation on the ground, as it evolves. If the planning process has been taken seriously (and not just another annual offsite event), then everyone involved grows professionally, learns about the status of the organization today, and unites around a common way ahead. For this to happen, the planning process needs to be well-structured, yet open to innovative ideas, best-practices, and benchmarking, and should involve a diverse group of subject matter experts. If the planning process is sound, then even if the plan needs to change based on circumstances on the ground, the people involved are able and prepared to adapt.

Eisenhower and Enterprise Architecture

Design and Enterprise Architecture

Design, style, and innovation are important communication mechanisms and are crucial to User-centric EA. These communication mechanisms are used in information visualization and is heavily used in EA to develop useful and usable information products that can be easily understood and applied.

Increasingly, design is taking center-stage across technical and everyday products in our economy.

The Wall Street Journal, 4 January 2008, reports in no less than three separate articles on the importance of design and style for everyday products from computers to hard drives and even storage containers.

Here are some examples from a front page article titled, “PCs Take a Stylish Turn in Bid to Rival Apple”:

• “Dell is trying to inject a sense of style into the company’s PCs, with new shapes, sizes, and color.”
• PC Makers are “racing to replace boring boxes with sexy silhouettes that will differentiate their products, entice new buyers, and command higher prices.”
• Forrester Research “issued a report last June heralding a new ‘age of style’ in the PC market. It concluded that more attractive models could command $150 to $200 more.”
• “During most of the industry’s 30-year history, PC makers didn’t worry much about style. A bigger challenge was boosting technical performance and wringing costs from suppliers.” Now an Intel anthropologist states “there is a sense of, ‘Oh my G-d, why does this have to be so ugly?’”
• Lenovo stated that now “designers have equal weight at the table.”
• Dell has gone from 6 designers in 2001 to 90 designers now and they are still recruiting.
• At the upcoming Consumer Electronics Show, Microsoft will hold a PC ‘fashion show’ with judges picking the top three designs.

Additional articles the same day point to the importance of design and style. For example, the article “Can a Hard Drive Make a Fashion Statement” states that Seagate “kicked off a new strategy at the 2007 Consumer Electronics Show, offering drives with sleek shapes and lights to woo users accustomed to iPod-like elegance.” And in another article titled, “The Struggle to Contain Ourselves,” about the briskly growing $6 billion storage and organization industry where “style is increasingly important” and “once just plastic bins in industrial blue or clear, specialized storage products are now available for most conceivable uses in an array of material, from bamboo to faux leather to sea grass.”

While certainly consumer products are different than information products provided by EA, there is clear understanding now that design, fashion, style, and innovation are critical in reaching out to people, getting them interested in your products (consumer or information), and that design demands a premium in the marketplace. As the Intel anthropologist stated “why does this have to be so ugly?” Similarly, I would ask why do traditional EA products have to so often be so ugly, difficult to understand and apply. Let’s transition the way we do architecture to User-centric EA and design innovative information products that capture our users’ attention, really “talk to them,” clearly identify problem areas, propose alternative solutions, and lead to better decision making. Our executives are busy people with challenging jobs. We owe it to them to provide information in User-centric EA ways.

Design and Enterprise Architecture

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.

Blogs and Enterprise Architecture

Backup and Recovery and Enterprise Architecture

Anyone who has lost information on their computer knows how important backing up your computer work is, and organizations spend large sums of money to back up corporate information assets.

ComputerWorld, 4 February 2008, reports that “Corporate IT Warms Up to Online Backup Services.”

It used to be everyone backed up their own data, but now things are changing with major storage vendors entering the online backup market.

Now the benefits are beginning to outweigh the costs:

• Cost savings on specially skilled personnel and equipment for backup and storage administration function
• Productivity gains from outsourcing the systems administration and backup
• Unlimited corporate storage capacity

The information security officer at the University of San Francisco states: “If you asked me three or four years ago [about backup], the economics would say, ‘build it yourself.’ However, as storage vendors enter the online storage business and work to address IT concerns [such as pricing and security], ‘I can’t imagine anyone doing it themselves.’”

Gartner says “the technology is slowly becoming more attractive to large companies, thanks to move into the hosted storage business by EMC and storage and backup rivals such as IBM, Iron Mountain Inc, Symantec Corp., and Seagate Technology LLC.”

“IDC predicts that sales of hosted backup storage services will reach $715 million in 2011, up from $235 million in 2007.”

Vendors are moving quickly to address the following issues:

• Acceptable pricing
• Security including encryption and authentication
• Bandwidth

So are hosted backup services worth the cost?

The vice president of operations and compliance officer of Lisle Savings Bank says “I’m not going to say it cheap; it’s not. [But] we felt what are paying for is really insurance against losing data. I used to cringe when anybody deleted a file and I had to find the tape.”

The IT director of a Fort Worth, Texas law firm noted that “the move to the hosted service quickly blunted management concerns about disaster recovery in the tornado-prone area. The online option also ensures that backup tapes will not have to be stored by a vendor that could carelessly allow them to be lost or stolen…It’s the wave of the future, if it’s not already here.”

From a User-centric Enterprise Architecture perspective, we must ensure the security of business and technical assets. This includes the confidentiality, availability, integrity, and privacy of corporate information. One way to protect vital information assets is through robust information backup and recovery services.

Backup and Recovery and Enterprise Architecture

Managing Human Capital and Enterprise Architecture

Human capital is one of the perspectives of enterprise architecture that I have been advocating for the Federal Enterprise Architecture to adopt.

ComputerWorld, 19 May 2008, has a good article on “How to Manage Brilliant People,” which can be applied to all everyone—brilliant or not.

Here are some of the best dos and don’ts (in my own words for the most part) and my two cents on them:

1. Manage results, not process—Identify the results you’re looking for, but don’t prescribe to others how they need do it. This is micromanagement plain and simple. I don’t like to be micro-managed and I don’t think others do either. Treat people like adults and give them the freedom to do their jobs (assuming they haven’t abused that freedom and trust in the past).
2. Vet ideas, then make a decision—Communicate with your staff openly and creatively. Everyone on the team has good ideas and can contribute to analyzing problems and working out viable solutions. Not everyone will agree on the solution, so after a reasonable discussion and analysis, it time for the manager to make a decision. Analysis paralysis is detrimental to you, your team, and your program. Better to make a timely decision and then course correct as new facts become available, then to wait and wait and wait. Time is a critical success factor for most important decisions. The marketplace waits for no one.
3. Be a good mentor, and learn from everyone—We all have something to teach others and to learn from others, because we all have strengths and weaknesses. It doesn’t matter if you’re the boss or the subordinate. For the boss, it takes a degree of humility and open mindedness to “be bested” and more than that to actually learn from it.
4. Admit what you don’t know, not just what you do know—Generally, we all are more than in a hurry to mouth off what we know and show off what we can do. But how many of us are quick to admit what we don’t know? It takes a degree of maturity to say that I don’t know, but I’ll find out and get back to you, and not “feel insecure and threatened.”
5. Raise the bar, and stretch your staff—Just like when setting organizational goals, you want them to be achievable, yet ambitious, so too with setting personal and team goals, they should be challenging, but doable. That way you keep productivity high and morale high and people know they are growing (not stagnant).

At a manager in the IT world, I have learned that technically, pretty much we can do anything (given the time and resources); however, the trick to good management is not the technical stuff, but rather the people stuff. People can be more complicated than landing a man on the moon that’s why we need solid leaders, plenty of management training, compassion and empathy for people, and the institutionalization of human capital as part of our everyday EA planning.

Some early things that I would suggest in developing a human capital perspective in architecture would be:

1. Identifying best practices and benchmarking leadership and management performance against them;
2. Establishing a framework for professional development and training in these areas;
3. Identifying key knowledge, skill, and ability areas for the organization;
4. Inventorying employees against #3;
5. Identifying gaps;
6. Creating alignment between function and talent; and
7. Developing performance plan templates so that everyone understands their roles, goals, and the rewards available to them for high performance.

Of course, there is much more that can be done, and this is only a beginning. This is something that I am very interested in and about which I would welcome any comments and feedback.

Managing Human Capital and Enterprise Architecture

Compassionate Change and Enterprise Architecture

Enterprise architecture, as John Zachman said, is about managing change and complexity.

Naomi Karten has an interesting op-ed in ComputerWorld, 19 May 2008, on change management.

Naomi writes: “managers don’t want to have to deal with the resistance and objections and pushback and grousing and grumbling that so often accompany change efforts.”

Change causes angst (hey, we’re all human!):

“The reality, however, is that turbulence is a fundamental part of the change experience. Replace what’s familiar and predictable with that which is unfamiliar, confusing, ambiguous or potentially risky, and people react…Almost any change (and sometimes even just the rumor of a change) upsets the relative equilibrium.”

Reaction to change is deep and occurs on many levels:

“People’s reactions are often more emotional and visceral than logical and rational. Some people display shock, anxiety, fear or anger. Some become preoccupied, absent-minded, forgetful, distracted or fatigued—even if they view the change as positive.”

Change management is important to successfully implementing change, modernization, and transformation:

“You can’t eliminate the turbulence. But you can minimize the duration and intensity of the turbulence, and therefore implement the change more smoothly and with less gnashing of teeth.”

So how do we help people see their way through change?

“What people need most in order to cope is communication in the form of information, empathy, reassurance and feedback.”

Aren’t adults really just big children, with fear and anxiety over the unknown? (Remember the “bogeyman” under the bed?) How many of you with children hear them express some nervousness right before the first day of a new school year or going to a new school or summer camp. It’s human nature. We are creatures of habit; change the structure we are used to and we’re like fish out of water, working just to catch our breath.

The truth is, all human beings are mortal and can be hurt by change. Cut them and they bleed. Pull the rug out from under them and they can fall on their face, especially if they don’t know first that the rug will be moving! That’s what change is—it’s moving the pieces around and expecting a person to know where things are.

As enterprise architects, leaders, change agents, it is crucial that we treat people with respect, dignity, equality and compassion. Yes, “business is business,” but we can elevate ourselves above the everyday tough business decisions, and recognize that our authority, initiatives, and change efforts have a human impact that we need be sensitive to. Part of enterprise architecture therefore needs to be building communication and sound human capital management into our IT planning and governance processes. For example, our transition plan to move from the baseline to the target state needs to not only address business process improvement and technology modernization, but also human capital management.

People need to worked with. They need to understand the changes taking place and how they fit in. They need to have time to adjust. They need support and encouragement. They need to be treated with humanity. Let’s not lose this in our effort to reach for the future state of the organization.

Compassionate Change and Enterprise Architecture

The Business Analyst and Enterprise Architecture

A business analyst or "BA" is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the business analyst typically performs a liaison function between the business side of an enterprise and the providers of [IT] services to the enterprise. (Wikipedia)

Business analysis is critical to enterprise architecture, because it derives the business functions, processes, activities, and tasks. Coupled with some basic data and systems analysis, BA determines the information requirements of the business and the systems (manual or automated) that serve those up. Through business analysis, we identify gaps, redundancies, roadblocks, and opportunities which are used by enterprise architecture to drive business process improvement, reengineering, and the introduction of new technologies.

Where does the business analyst reside in the organization—in the business or in IT?

The answer is yes to both. The business analyst resides in the business and works on segment architecture for their lines of business and on defining functional requirements. Some business analysts also reside in IT as a relationship manager to translate business-speak to the techies and vice versa. Also, the LOBs may not have business analysts on staff and may request this service be performed by the IT shop. For example, this may be done from the enterprise architecture function to support segment architecture development or alignment to the enterprise architecture. Or it may be done by the IT centers of excellence that develop the systems solutions. If they can’t get the functional requirements from the LOBs, they may send in their own BAs to work with the programs to help capture this information.

ComputerWorld Magazine, 12 May 2008, asks “Is there a place for business analysts in IT today?” And answers, “Not if their primary function is just to analyze business needs…business people want more than analysis; they want workable solutions.”

So aside from business analysis what do you need to come up with a technical solution?

• Resources—$$$$, smart people, the right infrastructure! (this one’s mine, the other two below are from ComputerWorld)
• Creativity—“come up with ideas…to create systems that can meet performance requirements.”
• Synthesis—“best ideas are evaluated and modified until good solutions are found.”

According to the ComputerWorld article, a single person who does the analysis, the creativity, and the synthesis is called a systems designer, but I disagree with this. The analysis and development of the requirements is “owned” by the business (even if IT is called upon to help with this function). While the creativity and synthesis, which is the technical solution, is “owned” by IT. Further, it is typically not a “single person” that develops the requirements and comes up with the solution. The solutions provider (IT) is generally distinct from the business that has the needs, even if sometimes it is difficult for them to articulate these into functional requirements.

ComputerWorld specifies four techniques for identifying requirements and developing a solution:

1. Group facilitation—“getting input from everyone who might have relevant information and insights on a business process.”
2. Process mapping—“create diagrams that capture task sequences for existing and new workflows.” (I believe we in EA all know this as Business Modeling).
3. Data modeling—“diagram the structure of the data those workflows operate in.”
4. User interface prototyping—“use prototypes of user interface screens to illustrate how people can interact with the system to do their jobs.” (Frankly, I don’t believe this one fits with the other three, since prototyping comes somewhat down the road in the SDLC after conceptual planning, analysis, and design. I would replace prototyping with some core system modeling to fill out the business, data, and system model set, so that we can see what systems are currently in use and where the gaps and redundancies are, and where there is potential for component or system re-use and building interoperability.)

I would suggest that 1 and 2 (the facilitation and business modeling) are the functions are the business analyst, but that 3 and 4 (data and systems modeling) are the responsibility of the IT function. Again, it is the business that “brings” the requirements and the IT department that comes up with the technical solution to meet those requirements.

Another thought: Perhaps the organization is struggling with defining the business analyst and those that develop the technical solution because it is really the synthesis of the two that is needed. It is similar to enterprise architecture itself, which is the synthesis of business and technology to enable better decision making. I can envision the further development of segment and solutions architecture to become just such a function that merges the requirements (business) and solutions (IT).

The Business Analyst and Enterprise Architecture

Frameworks and Enterprise Architecture

One of the issues facing IT professionals these days isn’t a scarcity of IT frameworks, but rather many good frameworks that can be in conflict if we do not sort them out.

Usually each framework is focused on a certain lifecycle, which on one hand helps align it to a certain view on things, but on the other hand complicates things further, because each framework attempts to be all things to all people, by covering an entire lifecycle.

Here are some examples of the frameworks and their associated lifecycles:

• Enterprise architecture – the IT investment life cycle (Capital Planning and Investment Control, CPIC)
• SDLC—the Systems Development Life Cycle
• ITIL –the service lifecycle
• PMBOK—the project lifecycle
• CMMi—the process lifecycle
• Configuration Management—the asset lifecycle

Each framework has plans that need to be developed, processes to be followed, reviews that get conducted, and go/no-go decisions issued.

If an organization attempts to introduce and utilize all these frameworks then there can result a major overlap of structures, processes, and reviews that can literally drive a project manager or program sponsor nuts!

The organization could grind to a standstill trying to comply with all these frameworks.

I believe that each framework has useful information and guidance for the organization to follow and that the key to implementing these is to determine which is the PRIMARY framework at various stages of IT. The other frameworks may overlap in the stages, but it is the primary framework that guides that each stage.

Here’s an example using a few of these:

1. Enterprise architecture is the decision making framework for IT systems. It has a core function in influencing IT investment decisions based on the target architecture and transition plan and EA reviews of proposed new IT projects, products, and standards. Therefore, EA is the primary or dominant framework in the planning stage of IT (up to the IT investment decision).
2. SDLC is the development framework for IT systems. SDLC has a core function is guiding the software development process. As such, SDLC is the primary framework for the development phase of the system (which comes after the IT investment decision and before operations and maintenance). Of course, SDLC has planning phases and O&M and disposition phases as well, but SDLC is the primary framework only in the development stage.
3. ITIL is the service framework. It has a core function in determining how service will be delivered and supported. ITIL is the primary framework for the O&M stage of the system (this comes after the development and before the disposition of the system), since that is when the system needs service delivery and support. Again, ITIL has other stages that overlap with other frameworks, for example planning and configuration management, but ITIL is the dominant framework only in the O&M phase.

The other frameworks should conceptually also assume a primary role for specific phases of IT and then pass off that role to the next framework that is dominant in that particular area.

4. For example, maybe PMBOK would have a dominant framework role also in the planning phase, looking at cost, schedule, performance, resources, risks, and so on (this would be after the IT investment decision of EA and before the development or acquisition phases). Again that is not to say that PMBOK doesn’t shed light and provide requirements for other stages of IT—it does—but it just is not the primary framework for those other stages.

I believe it is only by developing a unified lifecycle and assigning primary framework “ownership” to each stage will we be able to develop a truly workable IT structure and process for our organizations. As the saying goes: ”Two kings cannot sit on one throne.” So too, two frameworks cannot be simultaneously guiding our project managers and program sponsors nor taking up valuable IT resources.

The end goal is a single, simple, step-by-step process for our projects to follow with clear actions, milestones, and reviews, rather than a web of confusion and siloed, redundant governance processes in play.

Frameworks and Enterprise Architecture

Culture Drives Function and Enterprise Architecture

Isn’t it every kids’ dream to own a car? And who can’t wait to take their first driving lessons?

The Wall Street Journal, 29 February 2008 reports that “Japan’s Young Won’t Rally Round the Car.”

“Since the peak in1990, Japanese car makers’ domestic sales have dropped 31% to nearly three million vehicles in 2007.”

Why is this happening?

• The Internet—“Unlike their parents’ generation, which viewed cars as the passport to freedom and higher social status, the Internet-connected Japanese youths today look to cars with indifference…having grown up on with the internet, they no longer depend on a car for shopping, entertainment, and socializing and prefer to spend their money in other ways.”
• Preference for electronics—“Young people can borrow their parents’ car and I think they’d rather spend their money on PCs and iPods than cars….trains will do for now.”
• Green movement—“Many youths worldwide felt cars were unnecessary and even uncool because they pollute and cause congestion.”

Kids’ priorities are changing and with that car manufacturers are having to re-architect the way they design and sell cars.

How is the auto industry responding with new architectures?

1. New car designs for the Internet generation—these include smaller, eco-friendly vehicles; cars for hanging out together with convertible interior space designed to feel like a sports bar with large touch-screen displays that can be used by the group like; cars with rotating cabins “capable of driving sideways to easily slips into a parking space;” vehicles with “‘robotic agents’ shaped like a head with two eyes that s mounted on the dashboard abd provides driving directions in a soothing voice.”
2. New marketing for the computer-savvy— Drive date videos: “downloads filmed from a drivers perspective, the video lets a viewer go on a day drive with a young, female Japanese model as they drive together along scenic, congestion-free roads.”

The automobile is changing to meet new consumer demands: The cars’ purpose “isn’t to get from point A to point B, but is to provide a social space for the driver and passengers. It doesn’t convey status except the status of being together.”

A lesson for enterprise architects is that function certainly drives architecture. However, functional requirements change along with culture, and the architect needs to be ever vigilant is searching out and spotting new trends, so that the enterprise can be proactive in meeting user expectations. Further technical requirements change based on innovations, and these must be aligned with functional requirements to optimize EA solutions.

Culture Drives Function and Enterprise Architecture

Ask the User and Enterprise Architecture

The best way to find out what the end-user wants is to ask them.

The Wall Street Journal, 25 January 2008 reports on Ask.com that “Ask Searches for Answer to Luring New Users.”

Since 2006, Ask.com spent $140 million to Google’s $34 million on advertising between Jan. 2006 and September 2007, yet Google’s market share of the internet search business stands at 58.4% to Ask’s 4.3%, and “Ask’s market share hasn’t grown in the past couple of years, while Google’s…has seen its dominance increase.

Google is beating Ask based on “superior technology and word of mouth,” so the advertising is a moot point.

Jim Safka, the new head of Ask says that to understand the discrepancy, “the first step is figuring out who uses Ask today and what they use it for. We are not going to take wild swings.”

Apparently, Ask took some wild swings in the past without asking their users and ended up getting rid of the “Jeeves” from their original name Ask Jeeves.Com and getting rid of the “friendly butler designed to answer any question user posed him.”

Ask also goofed on a number of marketing campaigns which didn’t resonate with end-users, like “one campaign named ‘Use Tools, Feel Human’ [that] featured a primate [who] evolves into a human by using Ask.com.”

While “Ask’s market share continues to weaken,” Mr. Safka says that “Consumes are smart. If you look at the data and listen to them, the answer ends up being obvious.”

From a User-centric EA perspective, it is critical to ask the user what they want and understand their needs. One of the principles of User-centric EA is that we are focused on developing useful and usable products and services for the end-user; we do not build any information products that do not have a clear end-user and use. In contrast, traditional EA is often user blind and as a result develops “artifacts” that are difficult to understand and apply. Like Ask.com is learning, if you don’t understand your user’s needs, you end up with a lot of shelfware—whether it’s EA or search engines.

Ask the User and Enterprise Architecture

Systems Monitoring and Enterprise Architecture

When we log on at work, most if not of us get some sort of message that logging on connotes acknowledgment to monitoring and that there is no implied privacy to what you’re doing when logged onto corporate IT assets.

Monitoring is a way of life at work. It is part of information security, management oversight, and ensuring systems are running effectively (and preventing a severe network outage).

Kenneth Klapproth in DM Review, 22 February 2008 reports that network management tools are able to collect date “across the shared network to present real-time and historical availability, performance, and configuration statistics on individual services and applications.”

Cross platform monitoring and event management and resolution are important to maintaining the availability of today’s complex networks that are vital for corporate communications (voice, data, and video).

• ALERTS: Monitoring not only alerts IT personnel to when networks falter, but can also be set to provide alerts when certain fault tolerances are reached, so that IT personnel can take action before the network is brought down.
• CAPACITY: Network monitoring identifies not only when the network becomes overloaded, but also when there is excess capability that can be more optimally used.
• TRENDING: Performance is not monitored as snapshots in time, but also can provide historical trending that can provide valuable information based on usage patterns.
• VISUAL REPORTING: “Dashboard and web displays deliver visually compelling and graphically concise reports [of key network and capacity utilization trends] that enable organizations to make the right decisions faster and with more confidence.”
• QUALITY OF SERVICE: QoS is improved with monitoring. “Managers can see the current and historical use and performance of network resources, monitor and report on congestion, correlate QoS configuration with network performance, and use the information to improve traffic and service delivery.”

Additionally, many network monitoring tools have the ability for other key management features including self-discovery and healing. These features include: IT asset management, remote control, problem resolution, operating system set-up and configuration, software distribution, license monitoring, back-up and recovery, security, and lights-out management.

While network monitoring and management are more operationally focused, they are critical from an enterprise architecture perspective to ensure the delivery of core IT functionality for the enterprise: namely, a robust, sound, secure, cost-effective, state-of-the-art IT infrastructure upon which information can be delivered to the right people, anytime, anywhere.

Network management tools can also be helpful in building the enterprise architecture because of their asset discovery feature. With the ability to spider out over the network and touch anything with an IP address, these tools can help identify key enterprise architecture assets in order to establish the baseline and plan for future targets.

Systems Monitoring and Enterprise Architecture

ITIL and Enterprise Architecture

Both EA and ITIL are emerging disciplines that are growing in importance and impact.

Here are their basic definitions:

EA synthesizes business and technical information and develops information products and governance services to enable better decision making.

ITIL (Information Technology Infrastructure Library) “provides a comprehensive, consistent set of best practices focused on the management of IT services processes. It promotes a quality approach to achieving business effectiveness and efficiency in the use of information systems. ITIL is focused on IT Service Management, which is “concerned with delivering and supporting IT services that are appropriate to the business requirements of the organization.” (ITIL IT Service Management Essentials, Pink Elephant)

To me, EA and ITIL are mutually supportive. Here’s how:

• EA is a decision framework that provides for planning and governance. EA answers the question, what IT investment will we make?
• ITIL is a service framework that provides for execution of IT services. IT answers the question, how will we support and deliver on the IT investments?

In short, EA is the discipline that handles the decision processes up to the IT Investment and ITIL handles the service management once the decision to invest in IT is made.

What are the considerations for EA and ITIL:

• EA considers such things as return on investment, risk mitigation, business alignment, and technical compliance. EA focuses on business process improvement and new introduction of new technologies.
• ITIL practices areas include such services as incident management, problem resolution, change management, release management, configuration management, capacity, availability, service continuity, service level management and more.

How are EA and ITIL similar in terms of requirements management and their goals?

Each seeks to understand the business requirements and satisfy their customers: EA for the requirements for proposed new IT investments and ITIL for the service required to support those.

Both disciplines are goal-oriented in terms of wanting to improve effectiveness and efficiency:

• EA prescribes in planning, what are the right things we should we be doing (effectiveness) and in governance, how should we be doing them (efficiency) relative to IT investments.
• ITIL prescribes in service delivery, what are the right service deliverables (effectiveness) and in service support, how we should be providing service support (efficiency).

While EA and ITIL are complementary, ITIL picks up where EA leaves off—after the IT investment decision, but before the service execution.

ITIL and Enterprise Architecture

Competitive Sourcing and Enterprise Architecture

Our economy is heavily based on ensuring a competitive environment to drive innovation, cost-competition, and consumer value.

One of the reasons why mergers and acquisitions are reviewed so carefully is to ensure that they are not anti-competitive, which would result in antitrust action.

Competition law, known in the United States as "antitrust law," has three main elements:

• Prohibiting agreements or practices that restrict free trading and competition between business entities. This includes in particular the repression of cartels.
• Banning abusive behavior by a firm dominating a market, or anti-competitive practices that tend to lead to such a dominant position.…
• Supervising the mergers and acquisitions of large corporations, including some joint ventures. Transactions that are considered to threaten the competitive process can be prohibited altogether, or approved subject to "remedies" such as an obligation to divest part of the merged business or to offer licenses or access to facilities to enable other businesses to continue competing. (Wikipedia)

Competition law has been extended to the federal workforce as follows:

The Office of Management and Budget Circular A-76 mandates that “To ensure that the American people receive maximum value for their tax dollars, commercial activities should be subject to the forces of competition.” This includes the following activities:

“a. Identify all activities performed by government personnel as either commercial or inherently governmental.
b. Perform inherently governmental activities with government personnel.
c. Use a streamlined or standard competition to determine if government personnel should perform a commercial activity.”
The concept of A-76 is that without federal workers having to compete for their positions against for example, the private sector, then there is no way to ensure value for the American taxpayer. Where is the incentive for the federal workforce to perform if when they aren’t performing competitively, and they are not threatened with replacement by a better, more effective and efficient provider?
Federal Times, 12 May 2008 reports that “all indications are that as the Bush administration winds down, so too has its most controversial government reform: competitive sourcing.”
“Many in Congress have aggressively challenged the practice as being unfair and demoralizing to federal employees and last year they passed myriad reforms and restrictions that are already being felt.”
While I agree that competitions drive efficiency in the marketplace, I think A-76 has missed the mark in terms of reforming federal human capital.
Why?
Competing federal workforce against private sector contractors on a cost basis does not necessarily ensure best value. From an enterprise architecture perspective, we are missing something crucial in A-76 and that is the human capital perspective.
The human capital perspective on EA is one that was initially proposed by John Zachman, the founder of EA, and I am a strong proponent of it. Essentially, it says that just like the other business and technology perspectives of the EA, human capital is a filter through which you must make organizational decisions.
The human capital perspective of the architecture provides us an opportunity to optimize federal workforce performance in the first place, before getting to an outsourcing decision point. Additionally, if you can’t effectively manage your own workforce, what makes you think you can better manage a contracted-out function? (In the same issue of Federal Times, there was an article about how the federal procurement officials are resigning in droves!)
What can we do to first improve performance results from the federal workforce (and I’m not saying that there is any problem to begin with)? The same as with any organization—provide strong leadership to them. Provide them with a bold vision. Hire the best and the brightest. Accelerate the hiring and clearance processes. Make clear their roles. Inspire them as President Kennedy did when he stated “Ask not what your country can do for you, ask what you can do for your country.” Challenge the workforce and empower them. Provide training, career growth, and financial and other incentives. With these, the federal workforce can truly be competitive and best value—if not all the time, then certainly much of the time.
The enterprise architecture way to do this is to first, baseline your current workforce. Then, look at best practices, benchmark, and set the targets for your people. And finally, develop a transition plan to move your workforce from the baseline to the target.
There is much more work to be done in this area, and obviously this is just a cursory overview or sketch of what the human capital perspective of EA would do. On a personal note, this is an area of great interest to me and I look forward to exploring it further.

Competitive Sourcing and Enterprise Architecture

Classification Schema and Enterprise Architecture

User-centric Enterprise architecture captures organizational information, analyzes it, and classifies it, and serves it up to the end user in useful and usable ways to enhance decision-making.

I came across a helpful article in DM Review, May 2008, called “Ontology and Taxonomy” that clarified the classification schemas used in EA.

First of all what the heck is a classification schema?

Simply put, a classification schema is a way of organizing information by putting things into categories. This helps us make sense of the information by being able to relate items to one another. For example, is an item, part of a larger supertype? Does an item has subtypes? Are items part of a common set? Is there a one to one relationship, a one to many, or a many to many? An understanding of these relationships between information helps us to understand the information and better use it for sound decision making.

Here are the two classification schema:

1. Ontology—“includes putting things into categories and relating these categories to each other…an ontology is a model…’ontology concerns itself with the organization of knowledge’…the body of knowledge includes both class and instance.” Ontologies define relationships. In ontologies, we identify the intersection of different items with each other, so for example a man intersects with “person,” “male,” and “adult.”
2. Taxonomy—“A taxonomy is an ontology in the form of a hierarchy.” Typically, taxonomy takes the form of a tree diagram, with parent (class) and child relationships. Taxonomies are decompositions. “For example, a parent may be automobiles and the children may be trucks, SUVS, sedans, compacts, and so on. Then the children for trucks may be pick-ups, vans, refrigerated, etc.

One of the problems with taxonomies is that you cannot easily define everything neatly into categories and subcategories, such as in cataloging a body of knowledge. For example, in the Dewey decimal system, “Where do you put a book about the history of mathematics in the Islamic world? History? Mathematics? Religion? That points out the problem with most taxonomies. Most of our knowledge is not hierarchical.”

The limitation of taxonomies is why we need to use more sophisticated ontologies such as business, data, and system models in enterprise architecture to understand the complexity of the relationship between business processes, information required to perform those, and the systems that serve those up.

Classification Schema and Enterprise Architecture

Information Governance and Enterprise Architecture

We all know that information is vital to making sound and timely decisions. How do we govern information (the term information to include data and information) so that it is truly valuable to the organization and not just another case of GIGI (Garbage In, Garbage Out)?

DM Review, May 2008, reports on some research by Accenture that confirms that “high-performing organizations make far better use of information than their peers.”

Information is a strategic enterprise asset. The key to getting better results from information is the effective use of information governance. Information governance includes decision making and management over the full information life cycle, including: information capture, processing, storage, retrieval, and reporting and disposition.

Without information governance, what can happen to corporate information assets and the end users that rely on it?

1. Information Hoarding (or Silos)—the information exists in the organization, but people hoard it rather than share information. They treat information as power and currency and they do not readily provide information to others in their organization even if it helps the organization they work for.
2. Information Quality NOT (“multiple versions of the truth”)—information quality will suffer if decisions are not made and enforced to ensure authoritative information sources, quality control processing, and adequate security to protect it.
3. Information Overload—not managing the way information is rolled up, presented, and reported can result is too much information that cannot be readily processed or understood by those on the receiving end. It’s like the floodgates have been opened or as one of my bosses used to say, “trying to drink from a fire hose.”
4. Information Gaps—without proper requirements gathering and planning and provision for systems to meet information needs, users may be left holding the bag, and it’s empty; they won’t have the information they need to support their functional processes and day-to-day decision making needs.

Not having effective information governance is costly for the organization. The target enterprise architecture state for information management is to have the right information to the right people at the right time. Anything less will mean sub-optimized processes, excessive management activity, and poor decision making and that will be costly for the organization—lost sales, dissatisfied customers, compliance lapses, safety and legal issues, publicity snafus, and other mistakes that can even put the enterprise out of business!

According to Accenture’s survey of more than 1000 large companies in the U.S. and UK, information is not being governed very well today:

• “Managers spend more than one quarter of their work week searching for information.
• More than half of what they obtain is of no value.
• Managers accidently use the wrong data more than once a week.
• It is challenging to get different parts of the company to share needed information.”

The good news is that “the majority of CIOs seem ready to act” by employing information governance.

Information, as one of the perspectives of the enterprise architecture, is already governed through the Enterprise Architecture Board (EAB). However, to give more focus to information governance, perhaps we need to establish a separate Information Governance Board (IGB). I see the IGB as a sub-committee of the EAB that provides findings and recommendation to the EAB; the EAB would be the decision authority for governing all the perspectives of the architecture, including: performance, business, information, services, technology, security, and human capital. To better focus and decompose on the various EA perspective areas, perhaps they will all have their own sub-committees (like a Performance Governance Board, Business Governance Board, and so forth) similar to the IGB in the future.

Information Governance and Enterprise Architecture

Happiness, Human Capital and Enterprise Architecture

As those of you who are regular readers of this blog know, I am a proponent for a human capital perspective for the Federal Enterprise Architecture.

The human capital perspective would provide the people focus, while the business perspective provides the process focus, and the services, technology, and security provide the technology focus.

This would round out the established view of people—process—technology that fields like organizational development and enterprise architecture look to address.

From a human capital perspective, one critical item that organizations would of course look to baseline, target, and transition plan for is money—essentially, how we financially compensate our employees and motivate them with dollars and cents.

However, employees are not only motivated by money. People want to get up in the morning and not dread going to the office. So the human capital perspective can also look at other factors that make people happy, such as employee recognition, professional growth, challenging work, ongoing training, and so on. Making for a happy workforce, improves productivity, attendance, retention, and more.

The Wall Street Journal (WSJ), 2 April 2008, reports that there are three primary factors for making people happy:

1. Disposition—“whether you are, by nature, a happy person or not—there isn’t a whole lot you can do about this.”
2. Circumstance—“your age, health, marital status, and income.” Here the organization can impact income, but “this stuff isn’t nearly as important as folks often imagine. If your income doubled, you would initially be delighted. But research suggests, you would quickly get used to all that extra money.”
3. Activity—“how you spend your time.” Of course, there are “’engaging leisure and spiritual activities,’ things like visiting friends, exercising, attending church [or synagogue], listening to music, fishing, reading a book, sitting in a café, or going to a party.” I would add that the organization can also help here by providing employees with challenging but achievable, meaningful, growth-oriented activities. Both the spiritual/leisure activities and the appropriate work activities can all help people to be “happy, engrossed, and not especially stressed.”

The WSJ calls watching something like television “neutral downtime” It’s “low-stress and moderately enjoyable. But people aren’t mentally engaged.” So the benefits are not great. In this case, I would argue that a productive day in the office is more enjoyable than sitting home and vegging in front of the tube (although that occasionally can be therapeutic as well).

The key here is people need to feel engaged, productive, challenged, that they’re going somewhere and that it all has some meaning. Yes, we all need money to pay our bills, but there are other factors in work and at leisure that make for happiness. This is one area where the human capital perspective can play a role.

Happiness, Human Capital and Enterprise Architecture

A Natural Education and Enterprise Architecture

Anyone who has seen the amount of homework and stress our children are under these days would have to admit that our children are losing their childhood earlier and earlier.

The pressure is on for children to get the best early education so they can get the best SAT grades so they can get into the best colleges and universities so they can get the best and highest paying job so they can live a wonderful carefree life. WHAT THE HECK!

Someone please architect a better way to educate our children so that they flourish educationally, but still enjoy those treasured years.

The Wall Street Journal, 14 April 2008, reports that “While schools and parents push young children to read, write, and surf the internet earlier in order to prepare for an increasingly cutthroat global economy, some little Germans are taking a less traveled path—deep into the woods.”

“Germany has about 700 Waldkindergarten or “forest kindergartens,” in which children spend their days outdoor year-round. Blackboards surrender to the Black Forest.” The children, ages 3 to 6, spend the day in the forest singing songs, playing in the mud, climbing trees, examining worms, lizards and frogs, and building campfires. This is a natural way for children to spend their time and it aligns well with “environmentally-conscious and consumption-wary” attitudes.

Similar programs have opened in Scandinavia, Switzerland, Austria, and in the U.S. (in Portland, Oregon last fall).

A mixed bag of results:

“Waldkindergarten kids exercise their imaginations more than their brick-and-mortar peers do and are better at concentrating and communication…the children appear to get sick less often in these fresh-air settings. Studies also suggest their writing skills are less developed, though, and that they are less adept than other children at distinguishing colors, forms, and sizes.”

Is the tradeoff worth it?

In the U.S., the notion is generally, we have “to push academics earlier and earlier.” However, the back-to-basics approach of Waldkindergarten is challenging this thinking. One teacher summarized the benefits by simply stating, “It’s peaceful here, not like inside a room.” Another said that this natural education is a way to combat “early academic fatigue syndrome…we have 5 year-olds that are tired of going to school.”

I believe that if we teach children a love of learning and life, then they will thrive more than force-feeding them reading, writing, and arithmetic at age 3, 4, or 5.

We can architect a better education for our children. It starts with letting them be children.

From an EA perspective, we need to acknowledge that there is a baseline, target and transition plan for our children's education, and we do NOT need to get to the target state of advanced learning by putting undue pressure on children so early in their lives. In fact, if we understand that transition plans are just that—a transition from one state to another, in a phased approach of evolution—then we can indeed let children explore the world more freely and creatively at a young age, and evolve that incrementally with the skills they need as time goes on.

A Natural Education and Enterprise Architecture

IT Portfolio Management and Enterprise Architecture

“IT portfolio management is the application of systematic management to large classes of items managed by enterprise information technology (IT) capabilities. Examples of IT portfolios would be planned initiatives, projects, and ongoing IT services (such as application support). The promise of IT portfolio management is the quantification of previously mysterious IT efforts, enabling measurement and objective evaluation of investment scenarios.” (Wikipedial)

IT portfolio management is a way of categorizing IT investments and analyzing them to ensure sound IT investment decisions. IT portfolios are frequently evaluated in terms of their return, risk, alignment to strategy, technical merit, and diversification.

Why do we need IT portfolio management—why not just assess each project/investment on its own merit?

The added value of developing and evaluating IT portfolios is that you can ensure the diversification of your investments across applications and infrastructure; new systems/major enhancement to existing systems and operations and maintenance; new R&D, proof of concepts, prototypes, and pilots; between strategic, tactical, and operational needs, and across business functions.

ComputerWorld Magazine, 7 April 2008, reports that Hess Corp., a leading global independent energy company, developed creative IT portfolios based on three types of initiatives:

1. Bs—“business applications or business process improvement effort that’s aimed at increasing revenue or generating cost savings.”
2. Es—“enablers” or projects to support business applications such as business intelligence, analytical systems, master data management, systems integration.
3. Ps—“process improvement within the IT organization itself” such as standardizing the approach to applications development (systems development life cycle), project management, performance management, IT governance, and so on.

From an enterprise architecture perspective, we develop the target architecture and transition plan and assess IT investments against that. Again, rather than develop targets and plans and conduct assessments based solely on individual investment alone, EA should look at the aggregate investments by IT portfolios to ensure that the EA plan and subsequent investments are properly diversified. An EA plan that is overweighted or underweighted in particular IT investment categories can have a negative to disastrous effect on the organization.

IT investments represent significant expenditures to organizations and IT is a strategic enabler to mission, so messing up the IT plan with poor investment targets and decisions is costly to the enterprise.

IT Portfolio Management and Enterprise Architecture