/Tag: Community

Customer 2.0 Strikes

By |2011-12-28T01:52:56+00:00December 28th, 2011|Enterprise Architecture|

For those folks who don’t normally track the events of the Gamer community, I’d like to share a lesson that every consumer facing business should heed.  Social Media has changed the consumer landscape in an irrevocable way.  This incident demonstrates what happens to companies that don’t understand the new power of the customer.

In short, a small manufacturer hired a marketing company to promote it’s novel product.  Unfortunately, the marketing company failed to correctly handle the import paperwork, and the product was stuck in customs.  Customers who ordered the product for Christmas were not going to get their product in time. 

As you’d expect, some customers complained.  One in particular known only as “Dave.”  The marketing company made a couple of rather typical mistakes in handling the complaint.  The customer threatened to get the press and social media involved.  At that point, the company blew it.  Instead of taking a contrite and apologetic tone, offering to reduce the stress of the customer or even offering a discount on the order, the company representative sent a profane and inflammatory e-mail directly to the customer telling him, basically, to “get over it.”

That customer shared his e-mail with social media, and the storm started.  Within hours, the manufacturer has fired the marketing company.  The marketing company has been banned from at least one influential show (and my guess, the fallout won’t stop there).  The company’s image is in the toilet.  If they are still in business in a year, I will be amazed.

The business world has changed.  Customers have the power of community, and can act in groups in a way that they could never act before, at a speed that will make your head spin.  Companies who do not understand this fact will be left behind. 

Wikipedia and the definition of Enterprise Architecture

By |2011-12-13T14:27:15+00:00December 13th, 2011|Enterprise Architecture|

I was asked, this week, about a page that I had put into Wikipedia nearly three years ago.  Far from being able to take credit for it, I discovered that many of the edits made since I put the page up corrupted it to the point of uselessness.  Alas, after changing that page back, I checked out my favorite page: Enterprise Architecture. 

And it was unrecognizable.

The entire page had been rewritten by a single person (Matthew Kern) who, apparently, believes that “Enterprise Architecture” == FEAF (The US Government EA Framework).  While I applaud Mr. Kern’s desire to include cited sources for his statements, his decision to ignore all of the prior content and contributions and toss out all of the compromises along the way seems both short-sighted and arrogant, to say the least. 

I endeavor to let the current author settle a bit, and then change most of the article back, but for the sake of documentation, I wanted to share the direction that Mr. Kern wants to take the Wikipedia article on EA.  Gentle readers, do you agree with Mr. Kern’s decision, or do you support my intent to revert to the original material?

Previous Opening Section (compromise text) New Opening section
An enterprise architecture (EA) is a rigorous description of the structure of an enterprise, which comprises enterprise components (business entities), the externally visible properties of those components, and the relationships (e.g. the behavior) between them.

EA describes the terminology, the composition of enterprise components, and their relationships with the external environment, and the guiding principles for the requirement (analysis), design, and evolution of an enterprise.

This description is comprehensive, including enterprise goals, business process, roles, organizational structures, organizational behaviors, business information, software applications and computer systems.

Enterprise architecture (EA) is a term first used in print in NIST SP 500-167 a US Federal Government Document from the National Institute of Standards and Technology) in 1989. It is currently a mandatory practice in the US Federal Government: OMB Circular A-130 describes enterprise architecture and subordinate activities in some detail, in response to the Clinger Cohen Act (IT Management Reform Act) of 1996 mandatory requirement for government organizations (enterprises) to have an "IT architecture". The term has subsequently (after first use in 1989 by the US Federal Government) been used in foreign governments and in commercial practice.

According to the U.S. Federal Government: "An EA is the explicit description and documentation of the current and desired relationships among business and management processes and information technology. It describes the "current architecture" and "target architecture" to include the rules and standards and systems life cycle information to optimize and maintain the environment which the agency wishes to create and maintain by managing its IT portfolio. The EA must also provide a strategy that will enable the agency to support its current state and also act as the roadmap for transition to its target environment. These transition processes will include an agency’s capital planning and investment control processes, agency EA planning processes, and agency systems life cycle methodologies. The EA will define principles and goals and set direction on such issues as the promotion of interoperability, open systems, public access, compliance with GPEA, end user satisfaction, and IT security. The agency must support the EA with a complete inventory of agency information resources, including personnel, equipment, and funds devoted to information resources management and information technology, at an appropriate level of detail."

 

What say you?

EA Schools of Thought

By |2011-07-01T19:05:00+00:00July 1st, 2011|Enterprise Architecture|

As an Enterprise Architect, I’m first and foremost a problem solver.  I don’t like to ignore problems.  Yet, it appears that EA as a field has a problem and I’m finding it tough to ignore it.  What is the problem?  If you judge by the 1500+messages that have flooded the Enterprise Architecture Network on LinkedIn, Enterprise Architects cannot agree. 

How did I come to that impression?  Let’s look at the measures.  Across a handful of questions over the course of the past few months, there have been literally hundreds of responses.  Judging by the responses, we seem to have, as a group. different opinions about every facet of our profession.  We appear to disagree about mission statements, value propositions, metamodels, methodology, inputs, outputs, and the necessary levels of job experience needed to perform.

Certainly the impression is reasonable, but is it a reality. 

Yes and No.

There are a handful of “schools of thought” that emerge if you read and discuss.  The number of people in each school of thought varies, but there are some clear distinctions between them.  The biggest disagreements come from folks who are using the same words, but come from these different schools of thought.  

The following list is in alphabetical order.  Note that ALL of these folks have presented themselves as Enterprise Architects.

  • Alignment Architects – these folks are focused on interpreting strategy, making it actionable, and using it to scope and define business change initiatives.  Also referred to as Business Architects.
  • Application Architects – these folks are focused on implementing successful “enterprise applications” or “enterprise systems.”  Also referred to as Enterprise IT Architects (EITA)
  • Information Architects – these folks are focused on managing information assets at the enterprise level in a consistent way
  • Process Architects – these folks are focused on improving business processes or reorienting business processes to place the customer first.
  • Strategy Architects – these folks are focused on helping business leaders create new strategies, open new markets, develop new products, etc..

 

Just to make things interesting, the Zachman framework (ZF) is used by a subset of “alignment” architects as well as a subset of “application” architects.  So when you are discussing ZF, you aren’t even sure which perspective they are coming from.  It is just as easy to get two “alignment architects to disagree about the value of ZF as anything else. 

If you sort out the responses into groups on the basis of these different schools of thought, there is remarkable consistency among the answers.  That’s right: consistency.  People are saying similar things… sometimes even the same things… about the value, methods, and concepts of Enterprise Architecture.

Perhaps we need to split up the field into specialties, just as physicians have specialties, with some base training and a focus on a particular branch of medicine.  After all, an oncologist makes a reasonable diagnosis when you have a cold, as would an Emergency Room doctor, but in the event of a car accident, I’d take the ER doc any day, and in the event of cancer, I’m making a beeline to the oncologist. 

If we understand enough about an enterprise, and the problems that they want to solve, we can focus on a single specialty (and/or bring in the right specialist). 

Solve these problems

With these architects

We need new products.  We need to open up to new markets.  New opportunities have arisen.  New threats are recognized.  New competitive pressures are being felt. 

Strategy Architect

We need to be more agile.  We need to organize our business to deliver to our stated mission.  We need to get our strategies to be realized more quickly.  We need to cut waste.  We need to focus on what matters.  We need to implement new regulations.  We need to respond quickly to corporate mandates.

Alignment Architect

We need to implement more scalable technical solutions.  We need to integrate and/or replace complex areas of our line-of-business applications with packaged solutions.  We need to add process flexibility into our systems.  We need to consolidate business rules.

Solution or Application Architect

We need to make our processes more efficient and effective.  We need to reduce friction between business groups.  We need to minimize the cost of a business process, and remove waste. We need to refocus our processes on customer requirements and customer experience. 

Process Architect

We need to create a single version of the truth.  We need to reduce the amount of processing needed at each step of an information-based process.  We need to reduce the difficulty in producing consistent reporting.  We need to manage large amounts of information.  We need to improve the ability of business units to communicate through consistent information.

Information Architect

 

Perhaps if we begin to see that these folks are EACH needed, at different times, to solve different problems, we can spend much more time agreeing with one another.

Myths of Microsoft Culture

By |2011-03-27T16:25:00+00:00March 27th, 2011|Enterprise Architecture|

From time to time, I hear interesting anecdotes from colleagues or friends outside Microsoft, telling me a story about what it’s like to work at Microsoft.  Often these stories are placed into a comparative context, as in: our culture is different than Microsoft, because we do XYZ and Microsoft does ABC.

Of course, there is rarely an opportunity, in that conversation, to provide feedback on the basic assumption… that the person speaking has any clue at all about what it’s like to work in the innovation factory.  On one occasion, I did get the opportunity to ask about the source of their impressions about Microsoft, and I heard simply “everyone knows that.”  Bull-chips.

I’d like to examine a few myths about Microsoft’s corporate culture, and provide some anecdotes from my own personal experience that may provide a little insight.  Keep in mind that I’m not a Microsoft lifer.  I’m in my second stint at Microsoft, and have been there for about eight years now, but previously I’ve worked at: IBM Boca Raton, Racal Datacomm, American Express SROC, two small dot-coms (Fine.com and Acadio), various agencies of the State of Washington (Labor and Industries, Department of Licensing, Department of Health and Human Services), Los Angeles county, a tiny medical software company (DBS), the University of Tennessee Computing Center, and a couple of small retail jobs.  In other words, I’ve been a bit of a wanderer in my life, and I’ve seen a wide array of different “corporate cultures” at play. 

Myth: Microsoft employees work around the clock

Microsoft earned this reputation because our products mushroomed in complexity before our development processes had a chance to catch up.  Microsoft Windows and Microsoft Office became really big products at a time when there was no science, no literature, no guidance anywhere to inform us on the best way to build such big products. 

We’ve solved it. 

In all areas of the company, from product groups to sales teams, from operational divisions to support, Microsoft employees have, by and large, normal lives.  Sure, the software business is a creative business, and sometimes estimates are wrong.  Sometimes, a small team has to work really hard to hit a deadline that another small team depends on.  In exchange for that risk, there is the freedom for those small teams to be innovative… no one is telling them what to do, or how to create the future.  It is a balance, but one in which most employees thrive in.

Myth: Microsoft employees put work above personal lives

Absolute nonsense.  As an Enterprise Architect, I work with a very wide array of folks, way more than the average.  While a “typical” employee may interact daily with 10 people, my number is closer to 50, and I’m friendly and social with everyone. 

Here’s what I’ve seen: bicycle enthusiasts telling me about a mountain-biking trail they just discovered, Opera fans raving about the new Seattle Opera production, parents talking about visits to their children’s schools, volunteers sharing their efforts to help the homeless or teach children to read, and even a co-worker whose dog was part of the AKC/Eukanuba National Championship dog show.  My co-workers live full and rich lives, getting married, raising children, and engaging in communities around the world.  That’s the way it should be.

Myth: Microsoft doesn’t care about anything except money

This one hurts, but I’ve heard it.  I’ve working in many different organizations, and I’ve never seen or heard of a company that takes greater pride in giving back to the community than Microsoft. 

When Bill Gates left Microsoft to become the world’s biggest philanthropist, some folks in the business community were surprised, but we were not.  Bill always emphasized the importance of giving, and charity is deep in the culture of Microsoft.  (Before she died, Bill Gates’ mother was a senior member of the United Way of King County.  Compassion runs deep in the Gates family, and it runs deep in Microsoft)  Our annual fund drives for charity are large and very visible, but where other companies may consider that enough, at Microsoft, it’s only the beginning. 

This fall, I sat in a meeting with the CTO and all of his directs as he had each of his senior leaders stand up and describe their favorite charity and why they are passionate about it.  Every year, my department takes the day off and joins up with others to volunteer as a group at a local charity.  (This last year, we gave time to a shelter for troubled youth… the year before that, to a charity that trains work dogs for disabled people).  There is no pressure to give, but more than ample support for the message: giving is important and we celebrate the work that non-profit agencies do.  We have internal software tools for helping employees to plan their giving, and you can specify monthly deductions from your paycheck to be sent to the charity of your choice, matched 100% by the company.  Every hour you spend at a charity is matched by a cash contribution by the company as well.

During each major natural disaster, there are dozens of fund-raising events that spring up, completely unplanned but totally supported, to raise money for the needy.  (Including events, at the moment, to help victims of the earthquake and tsunami in Japan).  On the bulletin boards around the company, next to postings of someone’s garage sale, or a house-cleaning service, there are always posters describing some charitable cause or another (often supporting education for disadvantaged children around the world). 

Microsoft employees care.  This is one of the aspects of Microsoft culture that I love. 

Myth: Microsoft burns you out

People burn out of everything.  I once knew a guy who spent most of his time on the sofa after burning out of doing road construction work.  That said, in the early days, when we were still figuring out how to release large software systems, I’m sure that we had more burnout than other companies.  Creative people + seemingly endless hours can do that to anyone.

That aspect of Microsoft’s past is gone.  How do I know? Because Microsoft asks, and anyone can read the results.

Every year, every employee of Microsoft is asked to fill out a detailed 360-degree review of themselves, their team, their managers (all the way up) and the company.  The data is collected by an independent firm to insure absolute privacy.  We are honest about ourselves and each other.  The results are available, and we USE the data to improve.  Managers are rewarded on the basis of their “Workplace Health Index” (WHI) and those scores propagate upward, so that senior managers have incentive to mentor and train the managers below them. 

Burnout shows up.  Impending burnout shows up.  WHI scores dip and specific questions turn up that indicate a potential for burnout.  Managers that burn people out are retrained, and people notice when the workers below a new manager all start to shift to other teams.   I’ve even occasionally heard the phrase “rats off a sinking ship”.  But it doesn’t happen that often.  Not any more.  We’ve gotten better at promoting, training, and developing the leaders within the company.  As a result, the company’s turnover rate has dropped.  That said, if a manager sucks, his team will leave him or her for other opportunities in the company.

And this highlights another aspect of the culture: truly active support, by the HR department, to allow people to move from one team to another.  If you are unhappy with your position, or your interests have changed, or you want to try on a different set of skills, you are not only free to move; you are encouraged to move to another spot.  The company is large, the needs are varied, and the people are friendly.  There may come a time when you want a new job.  You don’t have to leave Microsoft to get it.

In just the past year: An architect that I’ve worked with for years just moved over to lead a team of business folks in his operations division.  A talented developer that I enjoy working with moved from the office of the CTO to the product group (SQL Server).  A senior developer who was also a good speaker moved from software development to software evangelism (yep, that’s a title at Microsoft: software evangelist).  Our chief Enterprise Architect, my manager, is about to embark on a new architecture role in the Interactive Entertainment Business (think: XBOX).  We shift all the time. 

In this environment, burnout just isn’t that much of a problem anymore.  If ‘softies burned out all the time, how is it that so many of my peers have been at the company for over ten years? 

Myth: Microsoft is a dreary place, with no opportunities for fun

This one is almost laughable.  Does your workplace offer you professional-quality soccer fields, baseball fields, basketball courts, beach volleyball courts, regular fully-funded “morale” events, social groups by interest, amazing Christmas parties (in a local downtown hotel, with drinks, food, dancing, entertainment, roaming photographers, etc.), a café complex that includes about a dozen local restaurants, an in-house bicycle shop, game rooms, video games in the common areas, pool tables, XBOX consoles plugged in to huge projection-size televisions (some with Kinect controllers), art work in every hallway and corridor (including some art pieces that are truly amazing, like the four-story light array in one of the Game Studio buildings), and open meeting areas for spontaneous conversation and collaboration? 

What about chances to be really innovative for creative types?  We have groups of people in the company that have formed around the meme of “individual innovation” including the “Microsoft Garage” group (anyone can join) that regularly gets together to work on fun side-projects.  I’m in that group.  In the past year, the garage has done everything from helping people to create nifty bits of software to building an entry in the Red Bull Flugtag! 

Myth: Microsoft doesn’t innovate

Every year, Microsoft hosts an internal conference, just for full time employees, where the rather large Microsoft Research organization sets up booths and the researchers present their ideas directly to the rest of the company.  In case you’ve never heard of Microsoft Research, this often-unheralded division of Microsoft is a well-funded world-wide pure-research organization.  Fascinating and useful innovations have come out of MSR as well as basic computer science research that universities around the world leverage in developing the new ideas of the future. 

This unique organization brings together some of the greatest minds in computer science to fund basic research, at the corporate level, not only to create new ideas but to bring them to life in the products and services of Microsoft.  Some of the examples of recent innovations in Microsoft products that resulted from MS Research are listed here.

Myth: Microsoft employees are in it for the money, not the love of innovation

In the past, when the stock was shooting through the roof and stock options amounted to the majority of Microsoft employee benefits, a large number of people came to Microsoft thinking they could get rich here.  A few did.  Those days are gone.  Now we make money the old-fashioned way… we earn it.  Guess what… the greedy ones have left.  Many moved to dotcoms.  More recently, the remaining ones moved to Apple, Google and others promising riches.  Many were dead weight.  Good riddance. 

The people who are passionate about innovation are very much still here, myself included.  We stayed because this is the best place on earth for an innovator to build something that actually works for millions of people, where software has fewer bugs than features, and where viruses are patched right away rather than months or years later.  

That said, let’s not discount the value of being compensated according to your value.  Personally, I think I’m paid fairly at Microsoft.  My salary is competitive.  I get the best healthcare in the State of Washington through Microsoft’s well-funded and well run health insurance program.  There are other perks too, including paid time off for a new baby (for both the father and the mother), adoption assistance, health club membership, life and disability insurance, and more.  Microsoft is even paying for me to lose a few pounds.  Of course, Microsoft still has plenty of millionaire employees.  (I park next to a Lotus sports car every day).  But these days, it’s mostly just a great place to work.

And yes, the fresh-ground coffee and soda pop is free.

Myth: Microsoft is a slow culture, plodding along at a slow pace

Which Microsoft?  Seriously. 

Some parts of Microsoft are involved with releasing really large and complex software products.  Our customers don’t WANT Microsoft to rush a new version of Windows or Office to market every year.  (Proof in point: a lot of people are still using Windows XP… 10 years old).  That isn’t a slow pace.  That is an intentional, rational pace that insures that new products have enough features for customers to justify an upgrade.  The free service packs and bug fixes come out every month. 

On the other hand, if you look at the divisions that are focused on consumer, hosted, and cloud services, we are releasing new services and capabilities at a rate that is as fast, or faster, than competitors like Amazon and Salesforce combined.  In the past few years, Microsoft has released cloud services in infrastructure, management, office applications, CRM, and even content delivery.  Many are free.  (I use my SkyDrive daily).  Some are already market leaders (Microsoft’s Content Delivery Network, competing with Akamai and about a hundred other companies, is already one of the top CDNs in the world in terms of traffic and performance). 

Microsoft competes in online advertising, search, and hosted personal services like e-mail and calendar.  We are investors in Facebook and a cable television network (MSNBC).  We have wildly popular retail stores opening up in shopping malls around the country, each carrying thousands of products with friendly enthusiastic staff to guide you.  Microsoft and it’s partners roll out new game and entertainment titles continuously, and the Kinect controller for the XBOX is now in the Guinness Book of World Records for the fastest selling new consumer electronics product in history. 

Culturally: time-to-market counts.  Now more than ever.  It shows in the way teams are structured, the way projects are aligned, the work that people do, the priorities that managers operate under, and the measures on senior management scorecards. 

Reality: Microsoft Is An Excellent Place to Work

I hit on many of the cultural myths I’ve seen play out.  I was motivated to write this post after hearing that another tech company nearby handed out stickers to all of their employees that said “No Microsoft Culture ”.  My response: you don’t know what you’re missing.

CultureSticker

I’ve been working at Microsoft for the past eight years.  I expect to spend another decade at Microsoft (unless I get some excellent career-building offer from somewhere else).  I’ve grown quite a bit in these eight years.  At Microsoft, I have a chance to contribute, to help change the world.  Some folks do that by being part of a small energetic company.  I’ve chosen a large, dynamic, energetic, fast-moving, caring, compassionate, continuously improving company… one with flaws, but one that cares about addressing those flaws. 

Last word: March Madness

OK, I have to share this bit, because it says so much about Microsoft.  Below are two photos taken at the same time from different angles.  They are taken in the cafeteria of Building 122 a few days ago.  In these photos, you can see large screens showing the College Basketball playoffs (affectionately known as “March Madness”). In the photo on the left, there is a good shot of one of the screens.  In the photo on the right, if you look carefully, you can make out the fact that there are three screens running at the same time. 

Two things to note:

  1. If you want to watch the games, you don’t have to hide at your desk.  Join your co-workers in the café, sip some coffee or have a snack, and watch the game. 
  2. Not a big crowd.  This day, there was one person, watching three huge screens.  Where is everyone else?  We are busy getting our work done so we can get home to be with family.  We have the option to goof off, but we don’t take it, because we enjoy the work we do.

 

MarchMadnessInB122-aMarchMadnessInB122-b

Update to Blogging Site

By |2010-05-25T10:14:04+00:00May 25th, 2010|Enterprise Architecture|

Hi Folks,

If you have wandered the wilds of the MSDN or Technet blogs in the past few days, you will have noticed that the blogging system has been given a facelift.  It takes a little getting used to, but it isn’t bad, all in all.  If there are articles or entries that are not rendering correctly, please let me know and I’ll work to get the problem fixed.  Thanks for your patience.

What does the brand of “Enterprise Architect” stand for?

By |2010-02-23T00:47:00+00:00February 23rd, 2010|Enterprise Architecture|

Fascinating, sometimes, what happens when managers assign job titles.  Today, I ran across a fellow, whom I will call Shawn, who works at Microsoft, and carries the title of Enterprise Architect.  Now, it is possible that Shawn has, in the past, had a job similar to that of an Enterprise Architect.  However, this person works deep in the heart of the software development team within Microsoft IT… in other words, even if he knows what an EA does… even if he wants to do the job… it is completely impossible for him to successfully perform the function of Enterprise Architecture given his position and location within the organization.

So, each time he introduces himself, and works to solve software issues, he creates an impression that Enterprise Architecture is somehow a function of software development.  And that hurts.  But it is not just him.  I’ve seen many folks with the job title of EA who, when they speak, or work, or post messages on online boards, are clearly not among the ranks of Enterprise Architecture.

And that got me to thinking… how much does the “brand” of Enterprise Architecture suffer when this mistake happens over and over?  In other words, how much does our profession suffer when people who are not positioned or supported to effectively act as an Enterprise Architect, or worse, have no idea what it means to actually perform the function of EA, carry around a job title of Enterprise Architect?

As many of you know, I’m not just an EA at Microsoft.  In addition, I’m the operations manager for my wife’s business.  In her small business, brand matters.  We are careful about when and where we use the brand, how it is used, and what it represents.  Brand is the “hook” upon which her business is defined in the minds of her clients and potential clients.  It represents her value proposition.  Brand matters, and we defend it.

But tonight, I am helpless to defend the brand of “Enterprise Architect.”

So I call upon the community to consider this: how can we effectively do the job of an Enterprise Architect, working with business managers, process planners, information architects, program managers, and techno-geeks, in a broad overarching role, depending on the good will, understanding, and contribution of so many others, if we cannot manage our own brand: our job title?

Add to that: on LinkedIn, there’s been a thread running for many weeks that started out as a simple challenge: describe the purpose of Enterprise Architecture in a 160 character SMS message.  I’m sorry to say that there’s over 300 entries, no two alike.  How can we defend our brand, and improve the penetration of Enterprise Architecture into organizations that would truly benefit from our presence, if we can’t even define the brand in a consistent and consumable manner?

Tonight, I’m venting.  I’m offering up frustration, but no answers.  For that, gentle reader, I beg your pardon. 

We are not much more than a loose band of feral housecats, beholden to no leaders.  We are fighting against ourselves, among ourselves.  Working against each other instead of working together to build the brand of Enterprise Architecture.  We exhibit the things we most deride in our business partners: lack of coordination, lack of leadership, and lack of vision. 

And as a result, we are unable to control our own brand.  Sad.

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. 

reworking my Architecture blogroll

By |2009-06-03T18:11:00+00:00June 3rd, 2009|Enterprise Architecture|

Many of the folks on my Architecture blog roll have been inactive, so I’ve dropped them.  There are other, newer blogs that may deserve attention.  If you know of a blog or wiki that covers Architectural issues, and you find it valuable, please send me the link so I can add it to my blog roll.  (Yes, you can nominate yourself).

Is it time to create an MBA in Business Architecture?

By |2009-03-05T13:40:11+00:00March 5th, 2009|Enterprise Architecture|

Assuming that “Architecture” can be generically defined as “the art and science of designing or constructing something” (adapted from here and here), then what exactly is Business Architecture?

Extending the generalized definition above, a Business Architect should be “someone concerned with the art and science of designing and constructing a business.”  Note the verb: constructing.  A business architect needs to be able to construct a business… from parts.

Reality check: How many people, with the title of business architect, are responsible for constructing a business? 

Most present business architects are technologists, concerned primarily with the alignment of IT projects to business strategies.  They may be planners or solution owners or process owners… but most work in IT departments of large organizations, often directly with the Enterprise Architecture function.

But if we take the view that a Business Architect is responsible for designing a business, or constructing it from constituent parts, then who should have the title of Business Architect?  Should it be an IT person… or should it be a business person?

I do not believe that Business Architecture is a technical function. 

In fact, I don’t believe that IT people do a good job, at all, of describing the architecture of a business, much less making design decisions about the structure, roles, responsibilities, and coordinated artifacts that make up Business Architecture.

But if it is a business skill, what do we get by applying the architectural approach?  We know what it means to be a business person.  What does it mean to be a business architect?

Operating as a business architect requires rigorous engineering skills, an understanding of patterns, and the ability to convey complex ideas through images.  He or she must use a rigorous methodology and clear visual language for creating rich diagrams that depict the business from different perspectives.  To build out the science, we need to create a comprehensive set of cost, flexibility, durability, and agility methods associated with producing viable designs.  Using visual models, business architects can review each other’s efforts, evaluate compliance, test for quality, and to produce detailed design that form the basis of activities.

In effect, if the impact of Business Architecture is to be fully realized, I believe that Business Architecture should become a rigorous and well defined science that is taught to people in Business Schools around the world.  Every MBA would be exposed to business architecture, and some graduates would focus on the profession.

I’m interested in seeing the development of an MBA program in Business Architecture.

Does such a thing already exist?  If you know, please share…

MBA in Business Architecture

It takes a village to raise an idiot (Wiki Non Wisdom)

By |2008-09-26T06:16:00+00:00September 26th, 2008|Enterprise Architecture|

I love wiki technology.  I’m an editor on Wikipedia and I enjoy contributing to community-based content.  The idea that individuals can contribute what they know to the rest of the world, and have it accepted at face value, is tremendous.  It is also a bit weird.

Recently, I returned to the Wikipedia article that I kept meaning to get back to: the article on Enterprise Architecture.  This is an article that had grown and morphed steadily over time, with each contributor adding bits of content in an ad-hoc manner.  While many people had something to say, an unfortunate few took the time to consider that the resulting article was less readable, more opinionated, and less useful than when they started.

I was guilty of that same crime.

I had made minor edits to the opening paragraphs a few months ago.  I didn’t take the time to really clarify things.  I just wanted to add… And there’s the rub with community based content.  No one is responsible for insuring quality.

Seeing that some changes had occurred since I last looked, I sat down to re-read it.  What an awful bit of text!  It was long, poorly written, with redundant material, and interspersed with conjecture and opinion. 

This time, I tried something different.  I took the time to discuss bits of text with other contributors, and considered multiple sources, before making a complete rewrite.  I made it much shorter and more readable, trimming out information that either could not be proven, or belonged in a different article on Wikipedia. 

It is not perfect.  It’s wikipedia.  If you don’t like it, change it.

Of course, now that I mention it here, a few dozen folks will go look, and my article will be changed within a few days to be unrecognizable again. 

Oh well.  At least it’s more readable now than when I started.

http://en.wikipedia.org/wiki/Enterprise_architecture