Inside Architecture

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

February, 2010

Posts
  • Inside Architecture

    Is there a Minimum Age for Enterprise Architect

    • 9 Comments

    This is apparently a discussion that comes up on a repeated basis on LinkedIn, and was asked again recently.  Fortunately, Jeffrey Smith (Chief Architect, Lockheed Martin) was kind enough to post a summary of the last time this discussion came up, and I’d like to share his words with you.  Excellent insight from the EA community on “the value of experience” in Enterprise Architecture.

    “While it is hard to determine when a consensus is reached on a forum like this, we did come to some general agreement. I will try and summarize what came out of that discussion as best I can from memory.

    1. We all agreed that it is experience, not age that is the determining factor. With that in mind, however, there is going to be a minimum age in order to gain the experience. Most agreed that someone under 30 marketing themselves as an EA either did not understand what EA entailed, or was being unrealistic. To be effective as an EA, the person must have a combination of business and technical experience that would be virtually impossible to attain at a younger age.
       
    2. We discussed the types and levels of experience that were required. Obviously an effective EA needs to have both technical and business experience to be effective. The amount in each category will vary depending on the person and the industry they are working in. Someone that wants to be an EA in an industry that relies heavily on technology would need more experience in the technology area than someone looking to work as an EA in a less technology intensive industry.
        
      It was also discussed that the both the technology and business experience ideally should be from working at a number of different companies. This was viewed as important to provide a more well rounded view than what would be seen in working for a single or very small number of companies. Every company has it's own approaches to both business and technology and understanding the different approaches allows an EA to better work in whatever culture they find themselves in.
        
      Experience in only on business approach or technology approach is just a limiting as having experience in only one technology area. The experience also needs to include working at management levels in order to get the big picture understanding needed.
       
    3. There was a discussion about various certifications and there value in determining the competence of an EA. While certifications can provide a good foundation for someone going into the field, certifications are no substitute for experience. By the same token, someone with 25+ years experience should not be viewed as unqualified simply because they do not have a piece of paper. For someone with 25+ years in architecture, going to get certifications is not likely to add much in terms of their skill as an EA.

    There has been a lot of debate about what makes a good EA, and I think this debate will continue for some time to come. The main part of the debate seems to revolve around whether it is better for EAs to come from a technology background or a business background. There are plusses and minuses to each. One thing that is needed in the EA field is the establishment of mentorship programs to help train the next generation of EAs. Successfully establishing industry recognized mentorship programs would go a long way towards advancing EA as a profession.”

  • Inside Architecture

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

    • 15 Comments

    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.

  • Inside Architecture

    The cost of “SOA-fication”

    • 5 Comments

    No, Virginia, there is no SOA Santa Clause.  SOA is not free.

    That said, if I’m changing a system to meet new needs, and I’m substantially refactoring a section of the code to deliver to those needs, SOA doesn’t have to be wildly expensive either.

    The myth of “expensive SOA” is just that: a myth.  If you have an existing system, and you are refactoring it anyway, it may make sense to spend a bit more money for “SOA-fication” (the process of turning a “closed system” into a system based on Service Oriented Architecture principles… if you can’t get all the way to “based on SOA,” I’m happy with “plays well with SOA.”)

    Of course, that cost is not trivial to estimate.  This is where I’d like to ask the community for your input.  What drivers have you seen to drive the additional cost of “SOA-fication” of an application?

    Here’s what I’ve observed…

    • “SOA Security” (Auth/Auth) - to insure that there are no additional risks to the enterprise through the availability of a previously inaccessible system feature.
       
    • Design and Design Review – to insure that the services being developed are truly worth investing in.  That means that the services exhibit good behavior for enterprise SOA services wherever possible (non-chatty, independent, transactional, reliable, traceable, etc.)
       
    • Testing – to insure that the interface is stable, meets the stated business needs, and can realize the stated design goals.
       
    • Monitoring – to insure that the service can be discovered / tested / validated and, depending on the service, that it correctly and reliably participates in Business Activity Monitoring and Workflow scenarios.

     

    Gentle Reader: Do these “dev cost drivers” coincide with your experience in turning legacy applications into SOA applications?  What “pitfalls” come to mind that are not listed?

    (I’m interested in actual experiences.  Please share.  There are no wrong answers here… just good people helping one another.)

  • Inside Architecture

    Business Architecture --- includes process architecture?

    • 5 Comments

    Debasish Mishra, a colleague of mine, posted recently that we should let Business Architects out of the “Business Process Optimization Prison.”  (link)  He raises some good points.  Chief among them is whether process optimization should be the sole focus of the business architect.  Quote:

    … a business architect who is narrowly focused on business process, organizations, and roles may have something interesting to tell the business sponsor but risks not being able to tell a complete story.

    I completely agree, but I urge care when reading his post.  Debasish is not suggesting that business architects don’t care about business process.  He is simply saying that business architects have to care about many other things as well. 

    Using your business architect for business process optimization is a bit like buying a Maserati race car to drive to the grocery store.  It can be done, but it’s not really practical, and certainly not cost effective. 

    Sure, many business architects are quite good at process optimization.  By way of comparison, I’m good at coding, but I don’t code anymore. 

    Similarly, a good business architect may have, in his or her past, been responsible for process modeling, measurement, and optimization.  But it’s no longer a focus of the work.  I’d go so far as to say that process optimization is not a necessary prerequisite skill for being an effective business architect.

    So use your business architect to do the work of a business architect: to model the business, and the business drivers, and to develop feasible well-aligned roadmaps for achieving goals.  That is where the real value of business architecture lies.

  • Inside Architecture

    Job Description for Business Architecture

    • 20 Comments

    As the result of reading some discussions on the responsibilities of Business Architecture, I got to thinking: How to describe the list of prerequisites for Business Architect, and what is the career ladder that I believe a good BA goes through?

    I did a quick bing search to see if other folks had attempted to answer this question.  While there are a few job postings on various boards, there are surprisingly few discussions of job skills or a job description.  One notable exception was posted in the summer of 2009 on the BPMI site, but that one is not particularly distinct from Enterprise Architect. (see below)  For this blog post, I started with the posting by Geoff Balmes from the BPMI site, made a few edits to clarify the distinction from Enterprise Architect, and posted it here.   

    Qualifications of a Business Architect

    Role
    The Business Architect analyzes the activities of a particular business unit or line of business and makes recommendations pertaining to the projects that the business unit should perform, in addition to relevant and timely corrections to the governance structure, business processes, and the structure of business information. This person illustrates the alignment (or lack thereof) between strategic goals and key business decisions regarding products and services; partners and suppliers; organization; capabilities; and key business and IT initiatives. The primary focus of this person’s work includes the analysis of business motivations and business operations, through the use of business analysis frameworks and related networks that link these aspects of the enterprise together. The Business Architect works to develop an integrated view of the business unit, in the context of the enterprise, using a repeatable approach, cohesive framework, and available industry standard techniques.

    Organization
    The Business Architect reports into business management and works closely with other business architects, enterprise architects, and counterparts in Information Technology. The Business Architect may have supervisory responsibility, possibly acting as coach and mentor to junior colleagues in a similar or reporting role. In addition, the Business Architect works though others at every level of the organization soliciting strategic imperatives from senior leaders and executives, and supporting business unit managers as they leverage business architecture artifacts to create their business plans. Finally, the Business Architect may provide direct input into the governance cycle for the funding, oversight, and realization of business projects.  In that governance role, the business architect helps to insure that business and IT projects are aligned to support the achievement of key goals, that specific business scenarios are considered and that business value is delivered. 

    Responsibilities

    • Develop a business architecture strategy for the business unit based on a situational awareness of various business scenarios and motivations.
    • Apply a structured business architecture approach and methodology for capturing the key views of the business unit in the context of the enterprise.
    • Capture the tactical and strategic business goals that provide traceability through the organization and are mapped to metrics that provide ongoing governance.
    • Describe the primary business functions of the assigned business unit in the context of the enterprise and distinguish between customer-facing, supplier-related, business execution and business management functions.
    • Enumerate, analyze, catalog, and suggest improvements to the strategic, core and support processes of the business unit, as needed, to support strategic and operational goals.  
    • Define the data elements shared between this business unit and other units in the enterprise and the relationships between those data elements and processes, people, systems, and other data elements.
    • Enumerate, analyze, and suggest improvements to the structural relationships of the business.  This requires the creation and maintenance of an ongoing model of roles, capabilities and business units, the decomposition of those business units into subunits, and the interplay between these units in various business processes, materials, people, and systems.

    Skills and Qualifications

    • A broad, enterprise-wide view of the business and varying degrees of appreciation for strategy, processes and capabilities, enabling technologies, and governance
    • The ability to recognize structural issues within the organization, functional interdependencies and cross-silo redundancies.  Those issues may exist in role alignment, process gaps and overlaps, and business capability maturity gaps
    • The ability to apply architectural principles, methods, and tools to business challenges
    • The ability to assimilate and correlate disconnected documentation and drawings, and articulate their collective relevance to the organization and to high-priority business issues
    • The ability to visualize and create high-level models (rigorous information-rich diagrams) that can be used in future analysis to extend and mature the business architecture
    • Experience developing and using these high-level models as required to collect, aggregate or disaggregate complex and conflicting information about the business
    • Extensive experience planning and deploying either business or IT initiatives (preference for both)
    • Experience modeling business processes using a variety of tools and techniques (preference for BPMN)
    • Exceptional communication skills and the demonstrable ability to communicate appropriately at all levels of the organization; this includes written and verbal communications as well as visualizations
    • The ability to act as liaison conveying information in suitably accurate models between the business unit and their counterparts within Information Technology.  The scope of this information includes business requirements, data constraints, business rules, models of strategy and motivation, processes, accountabilities, and many other business and IT operational needs 
    • Must be a Team player able to work effectively at all levels of an organization with the ability to influence others to move toward consensus.  Must be highly reliable, trustworthy, honest, and commitment oriented
    • Strong situational analysis and decision making abilities

    The Career Ladder of a Business Architect

    Describing the career ladder of a business architect is difficult for many reasons.  This is a new field, and the business architects that I know arrived at their career from different directions and are likely on different trajectories.  What I can say is this: becoming successful at business architecture is an extremely useful skill in many aspects of corporate life, and can provide very useful insight and connections into upper echelons of management. 

    To become a business architect requires strong business skills.  A degree in business is more than helpful… few business architects will succeed without one, although a decade or more of experience in an industry can make up the difference.  Note that I’m not focusing on consultants who perform a business architecture assignment, but rather on full time employees who would be able to perform this role.  A firm understanding of structural models is the next prerequisite skill and this kind of thinking is often found in people who “think visually.”  Look for creative individuals in accounting, marketing, and information technology who can tend to draw diagrams in their presentations that represent the relationships between concepts, people, processes, or business functions.

    Once you have proven successful as a business architect, the next step depends on you.  The obvious next step is to the role of enterprise architect.  To be a successful EA, one should have been successful at one of the key EA roles (Business, Solution, Information, or Technology Architecture) and have a reasonable grasp and appreciation for the other roles.  Not an easy step.

    Another direction for the successful Business Architect is into business management.  A BA can see relationships that most mid-level managers have never been trained to look for, and have a rich understanding of how to use that information. 

    How a Business Architect is different from an Enterprise Architect

    I personally consider an Enterprise Architect as a person who can perform as both Solution Architect (SA) and a Business Architect (as needed) and has some ability as an Information Architect.  In addition, an EA can perform at an enterprise level, something that is NOT required of either an SA or BA.  What this means, in my opinion, is that you should not call yourself an Enterprise Architect unless you have full capability as both a BA and an SA and at least partial capability as an IA.  (No, a course on the Zachman Framework or TOGAF is not sufficient). 

    In Zachman terms, an EA has to be able to perform across ALL ROWS AND COLUMNS of the framework.  A Business Architect doesn’t have to extend below row 2 or perhaps 3, while a Solution Architect usually lives in the lower rows.  An Information Architect, at the enterprise level, must be able to run the gamut of a single column of the Zachman framework. 

Page 1 of 1 (5 items)