Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

September, 2009

Posts
  • Inside Architecture

    Does EA need a name change?

    • 7 Comments

    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?

  • Inside Architecture

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

    • 0 Comments

    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.

  • Inside Architecture

    On becoming and being a Mensch

    • 0 Comments

    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.

  • Inside Architecture

    SOA Optimistic Data Synchronization considered harmful

    • 16 Comments

    Let’s say that you have two systems: Adipose and BellyFat.  They both need the same information.  Adipose handles customer transactions, so it needs information about customers.  BellyFat handles the long-term management of customer information, like what products they have purchased and what rights they own.  It also needs information about customers.

    How do we keep the customer information, in these two systems, in sync?  SOA offers three answers: Call-and-Response, Optimistic Data Sync and Pessimistic Data Sync.

    • Call-and-Response says: One system holds the data.  The other does not.  The system that does not hold the data calls the one that does, on a real time basis, and gets the data back quickly and efficiently.
       
    • Optimistic Data Sync says: Both systems keep a copy of the data.  If an event happens in either system, drop it on the bus.  The other system will get the event, interpret it correctly, and update its internal store to reflect the change.
       
    • Pessimistic Data Sync says: One system masters the data, but the other system keeps a local copy.  If an event happens in either system, drop it on the bus.  The other system will get the event, interpret it as best it can, and update its internal store according to its own business rules.  On a periodic basis, the ENTIRE data structure will be copied from the master to overwrite the data in the local copies (data refresh).

    Each of these three has its own strengths and weaknesses.  One of them, Optimistic data sync, is so bad, however, that I’d like to call it out for special ridicule. 

    Type Advantages Disadvantages
    Call and Response
    • Any data entity exists once
    • Less duplication of data, lower physical storage
    • One view of the “truth”
    • Diminishes need for ETL capabilities
    • Easy understanding for software developers that are familiar with relational database design
    • Consistent inter-system data models not requireed
    • Constrains architecture – provider and consumer must be “close”
    • Requires highly available data providers
    • Cumulative negative impacts on overall ecosystem reliability
    • Requires highly scalable messaging infrastructure
    • Fosters point-to-point messaging
    • Leads to rapid increases in complexity and management cost
    Optimistic Data Sync
    • Allows multiple systems to “master” a data entity
    • Diminishes need for ETL capabilities
    • Encourages loose coupling between systems
    • Supports systems that are wide distances apart. 

     

    • Requires highly scalable messaging infrastructure
    • Requires highly reliable messaging infrastructure
    • Assumes that data updates are always consistently applied
    • Data gradually gets out of sync, with no recourse to get it right.
    • Consistent data models are a necessity
    Pessimistic Data Sync
    • Does not require expensive messaging infrastructure
    • The amount of “correctness” between systems can be carefully managed
    • Encourages loose coupling between systems
    • Consistent inter-system data models not required
    • Requires system architects to agree that one system is a master
    • Data gradually gets out of sync, but administrator can use refresh mechanism to resync
    • Requires ETL capabilities

     

    You will choose one over the other depending on your tolerance for the “disadvantages” and your preference is for the “advantages” of any method.  However, and this is the focus of this blog post, one of these three is really not workable in the long run: Optimistic Data Synchronization.

    The reason for my enmity for this approach is simple: this approach uses an underlying assumption that is poorly considered.  That assumption is that it is fairly easy for two systems to stay in sync simply by keeping each other abreast of all of the events that have occurred in either one.

    The problem with this assumption is that it is NOT easy for two systems to stay in sync.  If the two systems don’t share an IDENTICAL data model, then each system has to interpret the messages from the other.  The rules of that interpretation have to be coded in each system, and that code must stay perfectly in sync.  Plus, there can be no errors in interpretation, or variations in the way that a change propagates throughout the recipient’s system.  There can be no variations in the event model between the systems.  No bugs either.  Sure…. if we can get to the point where no humans are involved in writing computer applications, then this might make sense.

    Not long ago, I used to think that Optimistic data sync was a good idea, and that SOA developers should assume that their data exists outside their systems.  Heck, I used to think that call and response was a good idea too.  Both are bad in practice, with Optimistic sync being by far the worst.  There are just too many common scenarios (like one system going down for a period of time, and coming back up after missing some messages) that drives down the overall integrity of data managed in this way.

    While I’d go so far as to say that Pessimistic and Call-and-Response are reasonable patterns for a SOA architect to select, the optimistic data sync method should be considered an anti-pattern, and avoided as much as humanly possible. 

Page 1 of 1 (4 items)