My Architecture & Governance Magizine Article: Business Architecture & Best Practices

Mike Walker Architecture and Governance Magazine

The new issue of Architecture and Governance Magazine is out. This issues is centered around the Business Architecture practice with elements of Information Architecture. It’s tiled, “Business Architecture: The Blueprint for Success?”

I was fortunate enough to be included in this edition. I speak about the definition of the Business and Information Architecture domains, their relationship to each other, and enabling techniques and models supporting each. 

You can find my article here: Walker Talks Business Architecture and the Best Practices for Using It 


To subscribe to A&G check it out at:


0 thoughts on “My Architecture & Governance Magizine Article: Business Architecture & Best Practices”

  1. Hi Mike,
    If I can quote:
    “I really think it’s as simple as this: Business Architecture is a disciplined approach for distilling a company’s corporate strategy into an architecture that’s implementable in IT terms.”
    So my take from this is the exercise of defining a ‘business architecture’ in this sense is that it’s eliciting requirements to be fed into the ‘IT Architecture’ – what’s the strategy, organisational structure, business data and how does the business want it to change?
    My devil’s advocate question: isn’t the process of building a “business architecture” nothing more than just a fancy name for requirements gathering? If not, why not?
    Another Mike


  2. Hi Mike,
    Thanks for taking the time to provide feedback. This also feel through the cracks due to the other lively debates (on the TOGAF Demystified Series) that were occurring as well.
    I would say it all depends on what you define as requirements.
    Most people think of requirements as at the project or program level detailing out specifics for a solution. If we are talking about those, then I would say no. If we are talking about requirements simply as, “something the business needs” then I would say yes. This is also how TOGAF describes requirements in the middle of the crop circle.
    From TOGAF:
    “The first high-level requirements are articulated as part of the Architecture Vision, generated by means of the business scenario or analogous technique… Moreover, architecture often deals with drivers and constraints, many of which by their very nature are beyond the control of the enterprise (changing market conditions, new legislation, etc.), and which can produce changes in requirements in an unforeseen manner.”
    I agree with the TOGAF position on requirements. But I am conflicted with the actual term used as it causes so much confusion.
    Thanks again!


  3. Thanks Mike – sorry missed your reply, seems I didn’t get an email ping..
    Yeah, I was thinking in terms of TOGAF requirements, which basically is the ‘raw material’ fed into the architecture definition process.
    So I’m wondering whether ‘business architecture’ as taken above isn’t simply putting more structure to the ‘requirements bubble’ in the centre of TOGAF, rather than a standalone slice of the architecture itself.
    Looking forward to seeing how TOGAF 10 treats this!


  4. IMO your close. I would still think that the Business Architecture phase stays as is. The collection, classification and the management of the requirements happen in the center, however the distillation of those I believe would happen in the Business Architecture phase. I think these are two discrete activities.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s