/2009

Why the Zachman Framework is not an ontology

By |2009-12-18T13:56:19+00:00December 18th, 2009|Enterprise Architecture|

John Zachman has been making an interesting claim in the last few years… he is claiming that the Zachman Framework for Enterprise Architecture, a creation of his that, through many revisions across the years, has formed a cornerstone of Enterprise Architectural practice in many parts of the world, is an ontology.

It is not.

Let’s be clear, first off, about the definition of an ontology.  There are two commonly used definitions.  In philosophy, an ontology deals with the nature of being.  An ontology in philosophy is a statement of “what is real”,  a conceptual understanding of something that helps to answer key questions, like “what things exist,” and “how does a thing relate to other things.”  Philosophical ontology attempts to answer questions like “does truth exist?” or “does energy exist?” 

Not long ago, the term ‘ontology’ took on a new meaning in the context of computer science.  In the late 1980s and early 90s, Artificial intelligence was attempting to create large maps of human understanding, and the term “ontology” started to creep into general use in AI circles. 

Tom Gruber is widely credited with bringing the term into focus in computer science.  In 1993, he wrote a paper titled "Toward Principles for the Design of Ontologies Used for Knowledge Sharing," later published in the International Journal of Human-Computer Studies.  The paper can be found here.  A more general discussion can be found here.

Gruber’s use of Ontology is fairly clear.  In the discussion cited above, he stated:

“In the context of knowledge sharing, I use the term ontology to mean a specification of a conceptualization. That is, an ontology is a description (like a formal specification of a program) of the concepts and relationships that can exist for an agent or a community of agents. This definition is consistent with the usage of ontology as set-of-concept-definitions, but more general. And it is certainly a different sense of the word than its use in philosophy.” (emphasis added).

The goal of ontologies in Gruber’s research was focused on Artificial Intelligence.  His challenge was complex: How could he get intelligent agents to converse with one another in a consistent fashion?  Ontologies provided that ability, far better than simple definitions would.  A concept in an ontology is defined rigorously, and the relationships between terms are specific and declared.

It is important to note that there are no implicit relationships between terms in an ontology.  Relationships, where they exist, are explicitly declared, and in many cases, constrained.  Relationships are not implied.  There is no notion that two terms may be related to one another, or not, as needed.

And here is where we come back around to Zachman.  While the Zachman Framework (ZF) defines, in a 6×6 grid. a self-contained set of terms, the ZF does not declare the existence of any relationships between them.  In fact, he implies that anything can be related to anything, without constraint.  While practitioners can reasonably discuss the composition of primitives into composite objects, the Zachman framework does not describe any composite objects at all. 

In defining a “type system” for “things related to enterprise organizations,” the Zachman framework provides a simple set of data types, and little else.  It is useful, but insufficient. 

Using ZF, I can look at a thing and figure out “where in my taxonomy does this thing belong?”  But the type system is too broad to imply many constraints.  The Zachman framework is full of generalities.  Specific types are not described.  This means you can understand a “thing” but not really talk about it at a conceptual level because it is too vaguely defined.  Specificity and clarity are required to draw conclusions.  That requires a great many more objects, and specific, constrained, declared relationships between them.

Without concrete objects and specified relationships, ZF cannot solve many EA-specific problems.  You cannot, using Zachman alone, have two people draw the same conclusions from the data that you collect, because your data is unstructured.  Conclusions come from structure and relationships, not definitional types.   You need a model that includes relationships to infer a conclusion drawn from the data.  EA needs ontologies (metamodels).

An ontology allows inference.  The Zachman Framework does not.

The Zachman framework is not an ontology.

Does IEEE-1471 Define Enterprise Architecture?

By |2009-12-13T14:04:06+00:00December 13th, 2009|Enterprise Architecture|

Michael Poulin recently blogged on EBizQ some of his challenges with applying IEEE-1471 to enterprise architecture.  For those not familiar with IEEE-1471, it is an ISO standard definition of “software architecture” that defines key concepts such as View, Viewpoint, Stakeholder, Model, and Architecture. 

For folks who would like a refresher on 1471, and how it connects to UML notions like element, artifact, and profile, see my prior post on the extended 1471 model that we use in Microsoft.

Using the concepts of Viewpoints and Views, Michael finds challenges in the notion that an Enterprise Architecture can be defined by the various views.  He correctly points out that the contents of the view can only illustrate the particular elements that are actually in the model itself, and if we don’t define the scope of the architectural model, then the views will not contain the necessary information.

Michael’s conclusion is “the viewpoints and views, so loved by the IEEE 1471 standard, do DESCRIBE but NOT DEFINE the architecture and the Enterprise Architecture, in particular.” 

With all due respect, I believe that Michael missed the point.  IEEE-1471 does not define the concrete enterprise architecture, nor the abstract enterprise architectural metamodel.  It defines the concept of architecture itself.  There are a few steps in the middle that need to be understood in order to bring all of these concepts together.  Saying that IEEE-1471 does not define EA is like saying “the concept of a Mammal does not define my cat Fluffy.”

IEEE-1471: a conceptual model for any architecture

First off, I don’t believe that Michael is challenging the core notion of IEEE-1471 itself.  The standard mostly defines terms and a semantic model, so that we can use those terms well.  It does not define how an architecture is developed, when, or who does the work.  It is purely a domain model for architecture.

Applying IEEE-1471 to “Enterprise Architecture” means that we will include, in the architectural model, all of the elements that are important to understanding the concerns of “Enterprise Stakeholders.” 

This is where we must re-apply IEEE-1471 beyond it’s humble application architecture roots.  The standard describes concepts that can be applied to any level of concerns, but only discusses those concepts within the context of software.  It is up to us to discuss those concepts within the context of the enterprise.  In Microsoft, we do exactly that, and we have no problem with using IEEE-1471 to define the notion of Enterprise Architecture.  The key is to use IEEE-1471 in the right context.

The diagram below illustrates the relationship that I will talk about in the rest of this article.

image

Applying IEEE-1471 to Enterprise Architecture

Applying IEEE-1471 to EA requires that we start with a single question: “Who are the stakeholders for an enterprise and what are their concerns?”  If we start there, we can capture those concerns, and create an “abstract viewpoint” that would be useful for creating the necessary views; views that describe and clarify those concerns. 

This process of “abstract-to-concrete” is useful, because it indicates the elements that we need to include in the architectural model itself.  Once we identify those elements, we know what information we need to collect from the enterprise itself.  We can actually scope our efforts, and justify the efforts to collect specific information, only when we understand the stakeholder’s concerns and the views we want to provide to meet them.

Note that the existing standard set of abstract viewpoints, defined in RM-ODP, does a very poor job of capturing the enterprise stakeholders and their concerns.  It is immature and in dire need of an update.

This is the clarification I would make on top of Michael’s post.  It is not about “defining EA by defining the views” (an approach that he calls “out-in”).  It is about defining the contents of an enterprise architectural model by first understanding the stakeholders of the EA model, and the concerns that they want to see addressed, and then creating an abstract viewpoint that you believe meets those concerns. 

This is not “outside in” or “inside out".  I argue that we should define the scope of your Enterprise Architecture efforts by the outcome you need to produce. 

How does IEEE-1471 relate to an Enterprise Metamodel?

Every model has a metamodel: a description of the elements within the model and how they relate.  A metamodel is, itself, a model, and thus has it’s own metamodel.  This hierarchy of models is well recognized, and the UML folks spend a considerable amount of energy and effort to describe the different levels, all the way back to a root level.  (Leave it to architects to want to understand the nature of any “thing".  It’s philosophy at that point). 

IEEE-1471 is a model that describes how you collect any kind of architecture.  In itself, IEEE-1471 is a metamodel.  Looking at it this way, you can create any model you want, as long as it works for your stakeholders.  It can be a model of an application, a business process, and yes, an enterprise. 

The abstract model, or ideal model, of an enterprise is called the “enterprise metamodel.”  This describes the elements of architecture useful for describing an enterprise.  I published part of an enterprise metamodel last spring in the Architecture Journal.   

Using views to decide what to capture in the EA model

Many medium and large organizations are sufficiently complex that it makes sense to hire an Enterprise Architect.  Any such “complex organization” can be viewed from many different angles.  Your “ideal enterprise architectural model” (or metamodel) can include hundreds of entities, some could contain thousands of rows.  Collecting that data in a consistent manner could take a very long time, but you will never collect all that data

You cannot, and should not, do the “ideal” thing.  You need to do the sensible thing… figure out what concerns your organization has, and which views on the ideal model will meet those concerns, and then collect only the information that you need. You only need to collect a chunk of information if you intend to create a view to meet the concerns of named stakeholders.  Limit your efforts to meeting the needs of specific people, not “abstract notions”  and, just their concerns; nothing more.

Inside Microsoft IT, we have a description of an ideal enterprise architecture metamodel.  It took Microsoft a considerable amount of energy, and money, to create it.  But I have no mysterious delusions that we will EVER populate that ideal model with actual data in every defined entity.  The ideal model is useful, because it helps our EA team to be consistent, growing our understanding in consistent ways, so that the data collection effort we do at one time supports the reports we need later.  But the ideal model does not define our work.  The concerns of the stakeholders define our work.

Closing Advice

My advice is this: don’t define the conceptual Enterprise Architecture as a set of views, but do define the concrete EA model as a set of views on an ideal metamodel… because those views have a purpose.  Know the purpose: to meet the concerns of EA stakeholders.  Those views are useful for selecting the entities you need to have, and the data you therefore need to collect.

Once you collect the data, you can produce the views that the stakeholders need, and answer the questions that the stakeholders need answered. 

That is the job of Enterprise Architecture, as expressed using the concepts of IEEE-1471. 

Modeling User Experience Scenarios

By |2009-11-10T19:01:00+00:00November 10th, 2009|Enterprise Architecture|

I’m working on modeling some requirements for a document management system.  I’m a big fan of using models to represent every element, from goals and strategies through to business processes.  From there, I model use cases and requirements and on down to system components that fulfill those requirements.  Just call me a traceability hound.

I find that the effort to develop requirements in this way is, if anything, substantially less than the traditional “text first” method, and I can always output text documents for those times when people need their Word Document.

User Experience Scenarios are not, however, an easy fit with our current modeling languages.  We have models for business processes (which are excellent for illustrating activities in the scope of roles), interaction diagrams (which are excellent for illustrating component lifecycles, timing, and information flow), and activity diagrams (which are excellent for illustrating the activity of a single module).

I am not completely comfortable illustrating a user scenario in any of these three visual languages.   They really capture the wrong information, and fail to illustrate the things I care about.

For a user scenario, I want to know what persona is involved, what motivation that persona has for interacting with my business service, and what information they will have before the scenario starts.  I also want to know what constraints they will expect of the scenario: what is their level of commitment to my business service?  How frequently will they be interacting, and what is their understanding of the underlying information?  While I can annotate one of the UML models above with this information, I cannot truly model this information in the UML diagrams described.

I’m using the following diagramming “language” to describe the connection between people, motivations, scenarios and use cases.  To see this sample full-size diagram, click on it.  The model attempts to show the people involved in creating and using architectural standards. 

Using a UML-derived diagramming language, I can document the scenario (labeled “<<Scenario>>” in the diagram) as a sub-activity diagram.  That activity takes on a sense of reusability, since it can be from the perspective of any involved actor while keeping the actor itself outside the scenario.  This allows a single scenario to apply to different people (Object Oriented Encapsulation, as applied to workflow).

Scenario model

On a different view (a different diagram), I can illustrate each of those scenarios with links to the constraints that I mentioned above (frequency, information objects, level of commitment. etc). 

The advantage of creating a model of this kind is obvious to me, because I’m a modeler.  But for many folks, the benefits may not be clear.  Let’s put it this way: if you change any one object or line, there is the potential for impacting other objects.  With a model of this kind, you can SEE those potential impacts before they happen.  By developing a model, the architect develops clarity of thought, and in doing so, reduces mistakes in the design.

I’m curious if others find this kind of model interesting.

How to Develop a Governance Program (that doesn’t suck the life out of your organization)

By |2009-11-06T18:00:10+00:00November 6th, 2009|Enterprise Architecture|

Enterprise Architecture has a role to play in both developing a vision of the future, and in providing governance and oversight to make sure that the organization can measure its progress towards that future.

The governance part is tricky.  Architectural Governance is part of a larger fabric of governance that needs to exist throughout the organization, not just in IT but also in the business groups themselves.  This means that governance has two masters.  Governance has to align to business value, on one hand, and “measures of compliance” on the other. 

For enterprise architecture, the business value lies on the proposition that systems designed with better architecture will be more flexible, maintainable, and reliable than systems that are not.  Measures of compliance, on the other hand, can include things like “numbers of projects reviewed” or “evaluated quality of architecture is trending upward.”

In my opinion, governance is about motivating people to do the right thing.  All compliance programs are really all about helping a person or team to do the right thing.  There are may ways to that goal.

Of course, it’s a challenge, in any society or organization, to define what it means to “do the right thing.”  I’ve noticed, as I conduct the architecture review program here in Microsoft IT, that there is a spectrum of governance.  Different people in the organization tend to fall somewhere along this spectrum.  Some folks want to “educate and encourage” good behavior, while others want to “monitor and inform” management about bad behavior. 

image

The reason that I point out this obvious fact is that your Enterprise Architecture governance program will have many components.  One component may surround innovation, and another may surround process improvement.  In my organization, we have a governance process around architectural standards and review

Each component will have an owner.  The owner is the person who is accountable for insuring that a particular behavior (do the right thing) is happening.  For architectural review in Microsoft IT, that is the Microsoft IT CTO Barry Briggs.   He also happens to own the measurements for our architectural repository. 

For each component of governance, it is important that you expose the governance owner to this spectrum and get agreement to the question: “Where on the spectrum do we want to be?”  Even better: add the element of time to the conversation.  “Where should we start?” and “Where should we end up?”

By getting your compliance owner to declare, specifically, where your compliance program needs to be on this spectrum, you are able to do many things:

  1. Everyone, including the compliance owner, knows and understands the posture that the compliance team needs to take.  Other folks may want to interject their own opinion about where, in the spectrum, compliance should land.  If the compliance program team members have a clear direction, then communication is clear, processes can be correctly designed, and expectations can be correctly set. 
     
  2. The compliance owners’ direct manager (often an executive) can have some idea about where the compliance program is going and why it is going there.  In some cases, this means that the executive can take responsibility for the level of risk they are accepting.
     
  3. Processes won’t get out of line with the intended behavior.  I’ve seen examples, from our consulting engagements, where the business wants to encourage a particular behavior, and they asked for compliance processes, only to produce the opposite of the desired effect. 

In one case, one of our partners was working with Microsoft on their SOA program.  Their IT Leadership wanted to improve the use of shared services. They developed a shared service reuse program and a governance model to make sure that everyone used the services.  The governance program was poorly rolled out and executed, and the program lost credibility.

As a result, whenever anyone asked about using those shared services, that person was derided and their idea discarded.  In order to get past compliance, managers created a crafty way to “game the system” in reporting the results.  While the compliance numbers looked good on paper, the actual use of shared services declined overall.  The program that sought to increase the use of shared services caused it to decline instead.

Compliance is part of the game when you are trying to encourage good behavior in an organization.  Making it work is not easy.  The person responsible for insuring that compliance occurs has to have the right level of ownership and accountability. But just as importantly, they need to carefully consider where, on the spectrum of governance their program should be, now and in the future, in order to deliver on business value without encouraging different kinds of  bad behavior.

Collaboration without common values is fruitless

By |2009-10-19T18:28:46+00:00October 19th, 2009|Enterprise Architecture|

One thing that any new Enterprise Architect realizes, on or around their first day of work, is that there are not very many other Enterprise Architects in their organization.  It is easy to look around and discover that you are the one and only Enterprise Architect, or part of a very small team.  That doesn’t do much to relieve the pressure, though.  An Enterprise Architect is expected to provide a lot of value, without a lot of direct resources. 

For this reason, a key concern of Enterprise Architecture is “how can I be accountable, and deliver value, without a lot of direct reports?”

This question is easy to answer: Collaborate.  It’s a lot easier to say than do. 

It is not enough for an EA to “want” to collaborate, or even to be “open” to collaboration.  Other roles can make that claim.  The EA has no choice but to “drive” collaboration: to make collaboration happen in situations where your stakeholders may actually be incented to ignore you, disregard you, or outright oppose your very existence.

And there’s the rub.  How does an EA create an environment of collaboration, and mutual interdependency, without wielding a large club?  There are many answers to this question, but the one I want to touch on, right now, is “the appeal to common values.”

Using the Appeal to Common Values

At the end of the day, it is impossible to force another person to do the right thing, especially if you don’t have the right to cause bodily harm :-).  You can appeal to their manager, but that only works when their manager agrees with you.  You can try to use logic, to convince them that your ideas are sound, but that doesn’t mean that they will be motivated to use your ideas. 

One thing that I think is key to success, necessary (but not always sufficient), is an appeal to common values. 

An appeal to common values goes like this:

  1. We both care about doing the right thing for our company.
     
  2. One aspect of doing the right thing is X (where X is a company value, corporate goal that you both share, or a common recognition of a problem that both of you want to solve).  Let’s both achieve X.
     
  3. We can achieve X better if we work together than if we are working separately.  We each bring our own requirements to the table.  However, since the end goal is the same, collaboration is better that competition.  (be ready to use measurement, logic, emotion, and/or incentive to back this point up).
     
  4. You can trust me to defend all of our requirements, and I’d like to trust you in the same way.  I’m trustworthy. 

Appeals to common values are effective because none of these statements is particularly difficult to agree with. 

For example, in Microsoft, we have company values that say that we will take on Bold Challenges.  We also have policies that say things like “use our own technologies where possible to solve our corporate needs.”  I can use both of these together to convince someone to adopt a new technology in an upcoming project, even if it adds some small project risks, because I can tie that activity (“use a new technology”) back to shared values (“use our own stuff” and “bold challenges”).

The fourth item above is probably the biggest part of the “appeal to common values.”  If we are working together to collaborate, at some level, we must trust one another.  My requirements and your requirements must blend.  We must both be accountable to all of the requirements, and we must both defend the other person’s requirements when our shared solution is challenged.  Otherwise, collaboration is a farce. 

This is sometimes overlooked, but without trust, an appeal to common values may produce no fruit.  On the other hand, without common values, collaboration can be difficult, or impossible, to achieve. 

The most difficult things

By |2009-10-13T21:42:05+00:00October 13th, 2009|Enterprise Architecture|

The single hardest thing to get a
person to do, is think.

If you can get a person to think, the next most difficult thing to get them to do is change.

Therefore, if you want people to change,
don’t ask them to think.

My father used to tell me, “You have two choices: getting someone to think, or getting someone to change.  Asking for both is asking for the moon.”  My father had a good bit of experience with both… he was a college professor.  A good one at that.

Of course, a college professor can consider himself successful if he gets someone to think.  Not so much for an Enterprise Architect.  We have to be able to go either way.  Sometimes, it is the job of an EA to get someone to think.  Other times, it is our job to get someone to change.

Thinking is tough.  If you show a business leader that a particular counter-intuitive action is a direct result of their own strategies, they will have to think about it… or just trust you.  That is the advantage of being a trusted advisor.  If the business leader trusts you, he can take the easy way out.  He won’t have to think, because you’ve shown him that you can be trusted. 

Change is tough.  In many organizations, Enterprise Architecture is not well integrated into normal planning and alignment processes.  You may have to ask people to perform tasks in a different order or to use a different set of inputs than they are used to.  You are asking them to change. 

The key here is not to also ask them to think.  Plan out the steps and walk them through those steps.  Show them how to do the “new” work.  Help them to understand why the “new” work is more valuable than the old work through any of a dozen different techniques (reference wins, emotional appeal, hope, common values, support for shared goals).  You aren’t asking them to develop the new process. That would require thinking.  You are asking them to do, not think, and giving them the steps.

Thinking or changing… pick one.  As an EA, know what you are asking for.

The Value of Enterprise Architecture

By |2009-10-03T13:10:09+00:00October 3rd, 2009|Enterprise Architecture|

“Waiter, Waiter!”

The customer sat in the corner of the busy cafe, with a seaming bowl of soup, frantically waving to the retreating waiter who had just set the bowl down and hurried away.  Frustrated, he turned, but did not advance.

“What is it, sir?”

“Waiter, try this soup,” the customer replied.

Curious, he walked back to the table.  “What is wrong with it.”

“Just try the soup.”

“Sir, is there a problem?” the waiter impatiently insisted, looking over his shoulder at the other tables.

“Just try the soup,” the customer repeated.  A few seconds of silence passed.  The waiter considered his options. 

“OK, sir.  I’ll try it.”  The waiter looked around the table.  “Where’s the spoon?”

“A-haaaaaa” noted the customer. 

I spent about two hours yesterday in a conference call with the Enterprise Architecture team of a large financial institution, one of the many fringe benefits of this job.  I shared some details about our EA practices and they shared theirs.  It was an opportunity for me to speak with peers, share ideas, compare practices, and such.  (Special thanks to their Microsoft Account Manager for setting up the conference call). 

One question that came up, that in fact often comes up, is “how do you convince senior business leaders of the value of Enterprise Architecture?

My answer: I don’t.  Enterprise Architecture, the function, is not valuable by itself. 

Enterprise Architecture is valuable because of the data that EA collects, and the reports that EA makes available to senior leaders. Allow me to repeat, it’s all about the data.

Business leaders don’t need Enterprise Architects to stand around acting smart.  They need data, reports, and analysis.  The Enterprise Architect is essential to interpret that data, and help them to understand the value of the using the information to make decisions. 

So, if I have a business leader who does want data, I start there.  I collect a little data and show it to her, and whet her appetite.  I ask what questions she wants answered (“Which processes drive the most cost to my department?” or “How much of my budget, last year, was actually spent on going after my priority strategies?”).  Then, get the subset of EA data needed to answer that question.  Projects grow from projects, functions from functions.  Data maintenance is expensive, so the reports have to be valuable year after year.

When we see a business leader that doesn’t understand EA, we show the reports we created for other leaders.  It’s all about the data.

To be honest, I don’t want to ever sell the value of EA to a business leader.  I want one business leader to ask another, “where did you get that data,” and have the other reply, “From Enterprise Architecture, of course.”

The system should flow from it’s own success.

If the data is the food, EA is the spoon.

Does EA need a name change?

By |2009-09-16T10:48:06+00:00September 16th, 2009|Enterprise Architecture|

Recently, Tim Westbrock asked, in his blog, if we should drop the term “Enterprise Architecture” when referring to the strategic business planning perspective within the EA role. 

“The question that I will leave you all with is this:  Can EA be successfully evolved to become a tool of business strategic planners, senior executives and boards of directors if we continue to call it Enterprise Architecture?”

To which Adrian Campbell replied, in his blog, that EA shouldn’t change its name.  Instead, Enterprise IT Architects (the term he applies to technical architects) should stop calling themselves Enterprise Architects.  Adrian argues:

“I would say that there has always been a difference between Enterprise Architecture and technical architecture.

The former has its origins in the Zachman Framework which has always included the business architecture aspects.

Technical architecture has evolved to become IT architecture and IT planning.”

Adrian is a smart guy.  He frequently conveys interesting and insightful viewpoints based in deep experience.  Unfortunately, he is rewriting history a little bit.  John Zachman was part of a team that developed the entire idea of Enterprise Architecture for the expressed purpose of aligning technology to business process, as a service offering that could be provided by IBM to allow their consultants to be more valuable to their business clients.

In other words, John Zachman invented a taxonomic framework useful for both Enterprise IT Architecture and Enterprise Business Architecture.  They are both in there. So using John Zachman as an argument why “upstart” IT Architects shouldn’t evolve into Enterprise Architects is an argument that is ill-informed at best. 

Other professions don’t change their names when they mature.  They create professional organizations, create standards, train practitioners, and police their own ranks.  Physicians of old are not physicians of today.  Engineers of old are not engineers of today.  Pharmacists of old are not pharmacists of today.  Professions change and grow. 

One thing that we do see as professions grow up: specialization.  Within the profession of medicine, we have seen a proliferation of literally hundreds of specialties.  A pediatric oncologist would not say that a cardiologist is somehow “not” a doctor! 

If it is a ‘problem’ that folks who work in one area of the Zachman framework have become aware of another area, and that is driving a desire to change the name, does that solve the problem?  Adrian finishes his post with “A sheep in wolf’s clothing is still a sheep.”  So if the wolf changes it’s name to “zebra”, won’t the sheep claim that it’s a zebra?  The entire debate seems silly, and a little xenophobic.

As we grow, as Enterprise Architecture develops, we need to provide for the possibility that many specialties can exist in the same profession.  One specialty will explore the art and science of developing business architecture.  Another will explore IT alignment in funding and planning, and another will explore technical architectures for IT systems.  More may appear.

Our frameworks are big enough to handle many specialties.  The question is: are our hearts?

Microsoft annual Day of Caring becomes part of National Day of Service

By |2009-09-14T14:22:00+00:00September 14th, 2009|Enterprise Architecture|

Now that the president and the United Way have teamed up to proclaim that 9/11 shall be honored, each year, with a national day of service and volunteerism, Microsoft jumped onto the band wagon in large numbers. 

Thousands of individual Microsoft Employees signed up for our annual Day of Caring activities, a tradition that goes back to the early days when Bill Gate’s mother used to lead the United Way in the Seattle/Redmond area. 

I’m proud to be one of them.  Many members of the Microsoft IT Technology Office, including CTO Barry Briggs, personally took part in activities to support a local charity that provides trained assistance dogs to handicapped individuals (For more information or to support Summit Assistance Dogs, please see their site at http://www.summitdogs.org/).  It was a morning of scrubbing kennels, bathing dogs, general maintenance, and learning about ways that we can support their good efforts. 

It was also a chance to get out into the community and show that Microsoft cares.  Microsoft’s support for charity is amazing.  As an employee, my contributions to non-profit agencies are matched, dollar for dollar, and my volunteer time is even matched with financial contributions from Microsoft.  I can submit records of my contributions, or, if I’d like, I can sign up to have automatic deductions from my paycheck made available directly to the charities of my choice (which I do). 

That level of support really makes a difference. As a Microsoft employee, I have given more to various charities in the last five years than in all prior years of my career combined.  I’m more proud of my employer, on the Day of Caring each year, than at almost any other time. 

Microsoft, on days like 9/11, proves to me that it cares about being a good citizen, contributing to the communities around the world where Microsoft can make a difference, and for that, Microsoft earns my respect and praise.

On becoming and being a Mensch

By |2009-09-11T12:56:47+00:00September 11th, 2009|Enterprise Architecture|

I mentioned to a Christian friend of mine, yesterday, that I consider him to be a “mensch.”  He was unaware of the term, and it made me wonder what other folks say about the becoming and being a mensch.  I ran across Guy Kawasaki’s blog post on the topic, but to me, his post didn’t really provide the meaning that I’d look for. 

First off, the word Mensch comes from the Yiddish and literally means “man.”  The real meaning is deeper, because, to be a Mensch means to be a “Good Man.”  The Oxford English Dictionary has an excellent definition:

In Jewish usage: a person of integrity or rectitude; a person who is morally just, honest, or honourable.  [OED]

So how does someone go about becoming a Mensch, and remaining one?  To me, there are a small number of rules:

1) Treat each person you meet in the manner that all people should be treated.  This goes beyond treating someone the way you would want to be treated… the golden rule.  I am a forgiving person.  If someone is rude to me, I forgive them.  But no one should be treated rudely.  To treat others as they should be treated is a higher calling.  It means to consider how all people should behave: to imagine the world that G_d would want us to live in, and then live there. 

2) To be an example to others of how people should behave.  This is a kind of humble leadership that implies that you behave as if a small child is watching you, learning from you, emulating you, each moment of the day.  That doesn’t mean to be perfect, but it does mean to be self-aware.  Do nothing that you wouldn’t want your son or daughter to be able to stand on stage, as a valedictorian, and cite as an example of your leadership.

3) To perform acts of love and kindness expecting no reward or recognition.  This goes beyond anonymous donation to good charity (although that is a wonderful thing to do).  This goes to everything from small kindnesses to your neighbors, to acts of random kindness to strangers, to moments of honest forgiveness to those that have wronged you.

4) Seek out those that you have wronged, and apologize.  There is a ritual among Jews.  Each year, as Yom Kippur approaches, each Jew is to actively seek out the people that he or she has wronged, apologize, and do their best to right the wrong.  An excellent post on this topic is here.  This is a huge part of being a mensch to me.  This act is one of the most humbling things you can do.  I recommend it to anyone, not just Jews.  You will feel better for it.

5) To heal the world, deeply and meaningfully.  There is an old tale of how the world was perfect once, but it has been cracked and broken.  Each person has a responsibility to heal it, to find a place where your special gifts allow you to close a wound, right a wrong, or stand up for the weak, helpless, or powerless among us.  Tikkun Olam.  Heal the world.  This does not mean that you have to help a thousand people.  You can help one deeply troubled soul.  Or you can teach, or feed, or clothe, or protect, or defend, or support.  Do what your gifts allow you to do.  Grow your gifts… nurture them… become the best you can be, so that you can heal the world in the best way that you can.

That, to me, is what it means to be a mensch.  To be humble.  Good.  Worthy of emulation.  Kind.  Honest.  Loving. 

One day, I will die and be buried.  The one thing I want someone to say of me, in honesty, is that I was a mensch.