17 July 2009

Enterprise architecture and business architecture

At the Melbourne BA conference I was asked to sit on a panel discussing what the differences and similarities of these two roles are.  I am not an architect and have not been one in any previous career.  So I wan't neccessarily prepared, and left that dscussion a little disapointed with where it went.

The discussion itself got stuck on how the Zachman framework is a full architectural framework that gos beyond technology.  Yep.  Okay, what next?

I'll throw up a few of my (still unprepared) thoughts here and see what comments I get.
  • Architecture is about designing in future capability, not delivering it
  • The differnece between enterprise architecture and business architecture is only a matter of terminology.  Or is it?  Mabe the business architure is less focused on the technical?
  • If you put up an architecture it becomes the baseline for change, and variations from it have to be justified (to some degree)
  • This means archicture should be an ongoing role and should generallly be flexible and open enough to accomodate new ideas
  • Like anything, context matters a lot
  • BAs are great candidates for architecture roles as they evolve through technology and business design
  • Why doens't architecture drive more business cases?
That last point is one I am curious about from a project perspective.  If architecture is about building capability, surely it should be able to justify investment.  Why is it that (technology) architectural elements are usually only implemented as constraints on projects?

8 comments:

  1. My thoughts on this are
    - Enterprise Architecture is a the function needed to optimise all of the IT Architecture on a global, enterprise level vs. optimising it on the project level

    - Business Architecture should identify the critical (think competitive advantage) business capabilities a couple of layers down that is then translated into IT capabilities, applications, systems etc.

    - Why not more Business Cases? Well for once, I think IT is constantly very weak in explaining what the value of reducing IT architecture complexity is. I mean in theory something as edgy as SOA gives business nothing, same functionality but as a service - So what is the difference? If only IT people could explain what flexibility and reduced complexity can mean....
    Well, we then would have world peace and well, a man can dream.

    ReplyDelete
  2. Dear Craig,
    In my opinion, the architecture enters in the BC to substantiate the options.
    In this case, it would supply the backbone to the project.
    Its value can be measured in its capacity to respond to business requirements. Then, it has to be flexible enough for accommodating some changes.
    Regards,
    Eugenio

    ReplyDelete
  3. It's interesting to hear your comment on Enterprise Architecture as being too technical for business architecture. As a software architect with an engineering background, I have found Enterprise Architecture as being less technical and more business focused than software architecture.

    Software architects are supposed to build for future capability but the only way to do that properly is to understand the strategic objectives of the business. Why plan for a future that nobody wants nor cares about? Many architects get distracted by the marketing efforts of technology vendors and fail to reach an adequate understanding of the kind of future that the sponsoring organization wants before they start planning for it. I feel that Enterprise Architecture is a corrective response to that failure.

    ReplyDelete
  4. Thanks for your comments guys.

    I think I agree with you all to some degree. EA is a great tool when sed properly.

    The questions standrds; what is the difference between EA and Business Architecture.

    Mr 4RugbyRd has suggested separating out EA from BA in a way, but I think the suggestion needs more elaboration. Care to have another crack at it?

    Regards and thansk again for the comments,
    Craig

    ReplyDelete
  5. I have done very little, if any EA, so take my thoughts as you will. Business Architecture should be a part of the Enterprise Arch. right?

    In that sense, Business Architecture should be a lot less technically oriented. A lot of Lines of Business, Processes we use to get our product to market, support it etc. While Enterprise Architecture has that and includes what Technical Infrastructure you use to support those Lines of Business etc.

    I think your last 2 bullet points are key. My, unsubstantiated guess is that Building architecture is a lot of work and effort ($$$) while value is not always apparent; Or the value is apparent, but there is never enough time to really do it right.

    Secondly, the Technical savvy gal develops the *architecture* artifacts. And whatever his/her passion or expertise is, is what will determine the content. Right or wrong.

    In the end, I think that it should be a collaborative effort to create EA/BA. This is difficult to achieve, of course, because you need technical knowledge, business knowledge, EA creation/documentation experience, and time. Getting the appropriate experts in a room to collaborate and agree would be like...well, you put your nice little euphemism here....but you get the point.

    This is a challenging effort when you do have the right people. There are always resource constraints and political jockeying....e.g., What's the $$$ value I can say I saved the company after delivering an effective Enterprise Architecture effort??? How then can I justify my paycheck????

    yes, ofcourse, there is value but how do you quantify it?

    ReplyDelete
  6. architecture certainly places constraints on design and subsequent building, such as choosing a one-story architecture for a house constrains the designers and builders.
    However, we can also look at architecture, especially software architecture as a statement of quality goals to be achieved by the system development and, for that matter, the project itself: the quality expectations of the architect, the designers, the customers, and management. Architecture renderings are usually done in a way that is understandable by the layman which permits input and discussion of those quality goals by everyone involved.
    At an insurance firm a decade back the business architecture was changed based on overall organizational strategy to bring the agents more under the umbrella of the corporation instead of totally independent contractors. This affected commission structure, support systems (human and computer), organizational hierarchy, and even location of branch support offices. One business architectural change that affected the enterprise architecture was the desire for more direct communication and information flow from the corporate databases to the agents. The enterprise architect team changed the enterprise architecture to include interactive voice response (IVR) in the infrastructure (servers, networks, wireless towers, software support, etc.).
    Both the business architecture team, working out of Strategic Planning at the executive level, and the enterprise architecture team, working directly for the CIO, spawned dozens of new projects. The difference was that the projects spawned by the changes to the company's business architecture did not all include IT changes. The commission structure change went through several projects before it reached IT with some minor changes in algorithms and data manipulation and storage. Similarly many of the enterprise architecture-spawned projects were totally transparent to the business while being driven by the high-level changes. The IVR is an example of seven independent but interrelated projects that made no visible change to the general operations of the company or agents. Until the agents were able to get client policy information over their cell phones, the enterprise architecture work went unnoticed except in budgetary meetings.
    That is but one example of the application of the difference between business and enterprise architecture.

    ReplyDelete
  7. To clarify my comment above:

    On a project the architect designs the systems architecture. This is done to fulfill the business/owner's technical and non-technical requirements. Limited resources and limited system capabilities make architectural trade-off decisions necessary.
    We all experienced that, I assume.
    However the system design is then cost-benefit optimised for the project. As some of you pointed out System/Business Architecture should be measured against technical and non-technical (incl. flexibility to accommodate future changes easily) requirements.

    Enterprise Architecture on the other hand is somewhat the design of a system of systems. Enterprise Architects should look at the architecture for all systems in a company. Especially the advent of SOA has shown how important such a function is. Or the quest to replace really really old legacy systems at banks. Projects which have not been undertaken because they don't pay-off well enough, but building around old systems created a convoluted architecture that makes change almost impossible.
    So Enterprise Architects design the system of all IT systems for a company.

    Layers/Starting pointy

    We design architecture in layers to translate business requirements into software and hardware architecture.
    For Enterprise Architecture the starting point is a bit more difficult to find. Since most companies can not identify the requirements for such task, I see that Enterprise Architects typically starts on the Business Process level. Once the BP are modelled they abstract them into business capabilities (e.g., book a ticket, pay a bill), then they look at the IT systems capabilities.
    Thus you identify IT capabilities lacking and overlapping functionality. And then you go down the full stack. What you come up with is a vision (mostly 3-5 years) of how the IT architecture of the company as a whole should look like. Thus it poses guidelines and limitations to projects and as such systems architecture.

    Execution
    Systems architecture executes itself. It is designed for the project in hand. The project is there to implement it.

    To execute Enterprise Architecture you need a controlling process. This typically is the IT project architecture review. An Enterprise Architect checks the system/project architecture against the long-term vision for the company.
    Blank spots and clean-up is typically done by initiating separate projects, e.g., implementing a new middle ware solution.

    The role of the Architect
    What does this mean for the architect? Well for once he has to document the architecture (business processes down to infrastructure). Secondly, he designs the overall architecture and actively drives the evolution of it forward.
    Thirdly, he acts as a senior architect on projects.

    My experience the first part of his role is about 30-40% of his time, whilst an architect typically spends 60-70% of his time on projects making the vision happen.

    -Alex

    ReplyDelete
  8. @Alex
    I think we are agreed that the enterprise architecture defines the overall IT structure to support the business processes. It clearly is a complicated task. Top down would likely be the better approach to capture all business processes in the most efficient way to produce the most efficient technology architecture.
    Since most organizations already have an architecture, even one that has been cobbled together over the years, it is a rare circumstance for an organization to step back and re-architect their IT functions in light of what the business is doing now.
    This brings up a couple of questions.
    Since most enterprise architects hail from the technical side of the house and are generally senior technologists with some deep networking, operating system, application design, or data administration knowledge, their deep knowledge of business processes are generally lacking. Where do the enterprise architects get their business process specifications? Are these technologists able to talk to, elicit, and understand the intricacies of, say, cashbox processes or annuities at a bank? There are few organizations that have permanent or even temporary roles of business architect. Is there some other role to help acquire, filter, and assemble the information about business processes for the enterprise architect?
    I'm also wondering how agile might play into this. Agile is somewhat bottom up, and prides itself in developing only what is needed now. When the organization is leaning in the agile direction does that invalidate the process of enterprise architecture?
    Finally, you have identified a primary role for the enterprise architect in the overall software development life cycle. Using the same company as an example, they had a small group of senior technologists who made up the enterprise architecture team. They worked pretty much full time in that capacity. One of their tasks was to review every set of requirements to evaluate the impact of the project on the architecture. Incidentally, the company had no systems architects; the enterprise architecture team worked with the project designers in that capacity. When the project required an alteration to the enterprise architecture, the enterprise architecture team went through its own life cycle of architecture change before the project could move into the development stage. The team had the authority to require changes in requirements or design and even to bring the entire project up for reconsideration when the impact on the architecture was negative or costly.
    In larger projects and those which impacted the architecture such as the aforementioned IVR project, the enterprise architect assigned to the development team also acted as systems integrator during integration testing.
    Most project managers, designers, and requirements analysts consulted with the enterprise architect assigned to their project during the course of their development activities.
    So the enterprise architect does not just sit in his ivory tower as a watchdog over the architecture, but is actively involved in the entire development process.

    ReplyDelete

Search This Blog