Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
Last week I had the pleasure of delivering a webinar for about our book “delivering EA with TOGAF and ArchiMate”. In this webinar I gave a brief introduction to the field of Enterprise Architecture with an emphasis on TOGAF and ArchiMate as two standards to help organizations be successful with EA. I illustrated these standards with practical examples from assignments.
The webinar was so well attended that I didn’t have the time to answer all questions afterwards. In this short blog posting we aim to fix that! Below I have attempted to cluster the questions into groups to keep the discussion focused and to the point. I have also included the original questions to help the attendees locate the answer to the Project Management Bookstore their specific question.
Q: In my experience as an architect, I have rarely seen EAs doing Business Architecture. Is that required from a technology perspective?
Unfortunately the term “business architecture” is very much overloaded, which has something to do with how people see EA. Some claim that “EA = Enterprise IT Architecture” in which case Business Architecture encompasses EA. Others argue that Business Architecture is part of EA (which is also how we see it).
Regardless of your definition: generally the goal is to look at the enterprise as a whole. In terms of scoping, it can be very rewarding to start with IT. In that case, though, make sure you keep the door open to grow and look at the bigger picture.
Q: Can you tell of some companies in the US who are using this?
Enterprise Architecture is a discipline that is used by organizations world-wide. The same goes for TOGAF and ArchiMate as two open standards in this field. Also, EA is used in pretty much all industries you can think of : Government, insurance, manufacturing, retail, health care, defense etcetera.
Starting with EA
Q: In capturing input process in EA, what methodology can we use to capture organizational tolerance level and cultural influences, that affect generally the overall process?
Q: Is it easier or more difficult to begin to apply Enterprise Architecture to a new organization or one that has been in existence for a while? Why?
Q: Do you have any tips for implementing EA in a start-up company or organization?
Q: Is EA more effectively applied organization wide, departmentally, or on a project level basis?
These four questions have a lot in common as they all touch upon some crucial points with respect to “how do we do / start with EA in our organization?”. The fact that there is no easy one-size-fits-all answer is well recognized. The TOGAF standard makes it very clear that it should be tailored to the specific needs of each organization.
This tailoring is very much dependent on such things as culture (are we a top-down governed organization, or more entrepreneurial and decentralized) and goals (are we aligned with the strategic process, or do we mainly focus on projects).
In other words: EA can be used in many situations, almost regardless of maturity level and industry. Look at what the organization wants to achieve, figure out how EA can contribute to these goals and then define/ tune the framework to make that happen.
EA practice and delivery
Q: Many of the graphic representations and workflow explanations seem to be Agile in nature. Would you say EA is agile?
Q: Your presentation seems to tie EA into Business Analysis, Agile and Project Management practices. Am I interpreting correctly? If so, can you please expand on that a bit? If not, please explain why.
Q: Would you say a lot of companies use aspects of EA, but just don’t understand how to formalize it further or the tools available to do so? Follow up to above Q: If my company feels like this, any tips for convincing management or my team members the value of EA application formally?
These three questions all pertain to the delivery of EA, and running a successful EA practice. The first one – on agility – is a big one. Quite often, people claim that EA by definition cannot be agile. I strongly disagree.
First, it is important to distinguish between two types of agility: (a) agility of the things we are building / realizing and (b) agility in the way we do that. An example of the former is the use of data virtualization techniques to be able to quickly (agility!) respond to new information requests by various stakeholders. An example of the latter is the use of sprints and short cycles to realize business value.
In my opinion, EA fits both. If agility is a key driver for the solutions we develop with EA, then this can be a large contributing factor to the agility of the enterprise, especially when combined with lean-and-mean EA practices.
This ties into the discussion about “cherry picking” practices from the realm of EA. In itself, this is a good thing: use what you need to be successful and do not worry too much about the rest. As mentioned during the webinar though: a fool with a tool is a still a fool making disaster faster. The key to success in the long run is to figure out how EA can support the enterprise in alignment with other practices such as project management, scrum teams, governance teams and so on. The rest (tools, templates, techniques)
If you have any questions that remain: please drop a note in the comments section below. Thanks for joining us and stay tuned, stay in touch!
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: