We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Will We See a Rise of "Business Architecture" to Extend Service Orientation Across Enterprise?

Vote 0 Votes
Joe McKendrick: Will we see a rise of "Business Architecture" to extend service orientation across enterprise?

7 Replies

| Add a Reply
  • Business Architecture is a "sine qua non" factor for the success of Enterprise SOA. How can one model Enterprise business services without a Business Architecture documenting the way the Enterprise is structured and works?

    Still, since the academy has done little in this respect the hope comes from EA practitioners. As such we might not see a BA for some time. Currently, there is no agreement on BA definition, scope, artifacts, framework or place within the EA. I recently posted a representation of the key entities and value chains of an Enterprise.

  • Absolutely - I've been talking for years about the need to use abstractions like service-orientation at the business level - rather than as a purely IT focused architectural style - as a way of enabling greater organisational adaptability and specialisation.

    I also agree with Adrian, however, that a concrete definition of business architecture is currently lacking despite many people having a personal and practical view of what it means. In a recent role as CTO of a company that was absorbing a rival I worked with business colleagues to use business capabilites (and their metrics) as the foundational structure for reasoning about the future of the business and lined all other 'implementation' assets (i.e. processes, organisation, technology) up behind them. We did this to explicitly focus on the core structure of the business and to enable reasoning about specific implementation strategies in the context of specific capabilities and avoid single-track thinking about how seemingly 'horizontal' issues (e.g. rewards, processes or IT) should be implemented in a 'standard' (i.e. overly simplistic) way across the business. This was definitely a 'service-oriented' way of thinking about the business itself (and intentionally so).

    Whilst it worked well - and we had an ad-hoc definition internally of what 'business architecture' meant to us - the framework was born out of the experiences and expertise of the people involved rather than adopted out of a text book or the practices of a consultancy firm.

    I think we do need more work on exploring this area and codifying good practice but suspect that there is no single method or small group of methods to 'define' and then 'solve' the problem of EA. Effectively enterprise architectures are fractal and made up of many components with different properties and which exist in different contexts and business models. Thus I believe we need to adopt some core structural idioms (like capabilities - the concept of business 'service-orientation' for adaptability and abstraction purposes) but then apply tools from different disciplines to ensure that our reasoning and implementation strategies do not become too one-dimensional across all capabilities (a major problem that has dogged many 'one-size-fits-all' EA programmes to date, IMHO, and which often therefore makes them lack clear context and value to the business).

  • My answer is - absolutely. I've been promoting this issue for 2 years already.

    To Adrian Grigoriu's "Currently, there is no agreement on BA definition, scope, artifacts, framework or place within the EA. I recently posted a representation of the key entities and value chains of an Enterprise" - I believe that value chains in BA is a cul de sac; BA based on SOA will operate in services based on Value Networks, like business executives do.

  • When one or more mega ERPs cover 70% or 80% of your processes, what is the point in creating a BA? Isn't it enforced by the presence of the ERP?
    In a more fragmented landscape, why not revert to an ERP instead of integrating different systems?

    • Because an ERP cannot act as a single source of record by any means. It is not designed to create anything remotely resembling a BA.
      I really think you are answering your own question, by correctly stating that an ERP only covers 70-80% of the processes and we are not even talking about roles, objectives, services, or any associations. And we are not even going into the whole topic of deriving information, or facilitating collaboration.

  • Despite of the limitations of current "Business Architecture" and the limitations of Enterprise Architecture, "Business Architecture" will evolve and will be used more often.
    It will be used more frequently because tighter Business and IT Alignment is a must: unlike other types of Components SOA Services boundaries are defined in Business terms and not in Technical terms. Business Process Management (BPM) and Business Intelligence (BI), which are closely related to SOA clearly represent Business entities.
    The other main reason supporting my case is the growing Business and IT Complexity. Abstraction in general and Architecture in particular is needed for reducing Complexity. For extended discussion of Complexity read my post STKI Summit 2010: The Effects of Infrastructure Compexity http://avirosenthal.blogspot.com/2010/04/stki-summit-2010-effects-of.html

  • The rise of business architecture is happening quite separately from SOA, but there is a very important connection between the two. Business architecture transforms the center of business-IT collaboration from lists of siloed project requests to the coherent design of business outcomes and what it takes to achieve them. SOA-based business services, by encapsulating an organization's major business transactions, provide a "model" of an organization's business capabilities in the digital world, creating a foundation for transforming our technology implementations from siloed applications into a modular, coherent business-focused design. Marrying the two, business architecture identifies (among other things) our core business capabilities for SOA-based implementation, and SOA enables the design captured in our business architecture to be carried forward into our implementations.

Add a Reply

Recently Commented On

Monthly Archives