I believe that for every strategy you want to execute via EA planning you need all the BITS – business, information technology and solution architecture. Without the business architecture you are just doing IT architecture and risk technology for technology’s sake implementations. A well-defined business architecture is a prerequisite for developing a successful EA future state and defines how the business moves in response to strategic change. It also provides both the business and IT organisation with a better understanding of the business designs for the future that the technology must support.
I agree that as a profession EA struggles with the development of this critical piece (including most of the various frameworks and practitioners). Often this is due to a lack of understanding of the business, its relationship to IT strategic change and an inability to break down the perceived vastness of the business architecture into smaller, more easily delivered elements beyond process models. Most perspectives make it too large and complex to comprehend, let alone to start to develop in a just-enough-just-in-time approach or limit understanding of all the aspects (i.e. UML models that IT understands not the business) that the business (not IT) needs to change.
To further complicate matters, many constituencies that impact the business architecture are often isolated from the EA team (as you discuss in your breeds of business architects Steve). Many other focus areas or people that act in the business architecture arena: business analysts, business process professionals, business managers, integration architects, risk and compliance professionals, HR professionals, etc. This is a considerably large group of players all trying to develop and manage elements of the business architecture and often isolated from each other.
I like to think of business architecture like I do the technical architecture as:
• Components (bricks): define individual business processes (these may be broken down into sub-processes or tasks), people, business rules and assets. The level of detail will vary from org to org.
• Domains: group business process, people and assets that reflect functional view, business units, roles, geography, and organisational structure.
• Patterns: organise processes, people and assets into groups that reflect an end-to-end perspective: i.e. business operations, product lines, business events, organisational design, and business activity.
• Services: represent a set of processes, people and assets that are delivered as a single unit and reused in this exact format every time. For example, "create new employee" adds a person to payroll, phone lists, and security; assigns a role and places it within a functional structure; aligns performance management; and so on. These may relate to business events, goals and objectives, business activity, geography, and roles. Sets of services are used for fiscal management, human capital management and performance management.
I have also seen people use Zachman very successfully to deliver business architecture – one client organised it this way – they relied heavily on the Zachman Framework for the managing constructs to the business architecture artefacts. The work products are itemised in a typical Zachman fashion:
• The how — business process model
• The why — business motivation model
• The what — information model
• The when — business event model
• The where — locations model
• The who — organisation and roles model
• The integration of all the above in a relationship model
Without business architecture you do not see a complete or holistic view of where change is required to execute strategy and risk filling holes with technology when it may be unnecessary. IT is just part of the operating fabric of the business and in modern organisations EA without comprehensive business architecture will become obsolete.
Comments