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

Is it time to break enterprise architecture up into specialties?

Vote 0 Votes
Nick Malik has an interesting point in this post, EA Schools of Thought, where he says, "Perhaps we need to split up the field into specialties, just as physicians have specialties, with some base training and a focus on a particular branch of medicine?" What are your thoughts on this? 

8 Replies

| Add a Reply
  • It seems there's always someone trying to fix what ails Enterprise Architecture. This should be seen as a major red flag. Awhile back I commented that I like to use the term "multidimensional architecture" instead of EA as it's really about applying multiple disciplines in a holistic manner toward a particular scope, which may not be Enterprise.

    Related to that, I disagree with Nick's recommendation for the very reason I state above. It's the applicaiton of the multiple disciplines into a holistic perspective that is important. By breaking it down into silos, there will be competing viewpoints and perspectives that will render a consensus-based solution instead of an best practices solution. Ultimately, I believe following Nick's suggestion would yield lower quality results instead of higher-quality results.

  • At the end of the day, you need someone who has the final say in these matters. I think the concept of having people specialise can make sense if there is someone with the bigger picture taking all of the input on board and making a decision based on that. Consensus is important but not absolutely required once people can bury their egos. Ultimately I think an approach where there are differing views is to try each in a small, quick project to see how it works. This will generally determine what is better technically or even for the organization. A well run 'bake off' with well defined measurements of success can ensure the best approach is taken and will avoid ruffled feathers. If both are still equal at the same time, the main person must make the call. If the person whose approach is not selected cannot accept that, it may be time for a new job !

  • If we break EA up into specialties, I would only advocate the specialties be organized by vertical, industry specific specialties. There is a core EA skillset that isn't specialized at all (i.e cross-industry) that makes up 80% of an EA's expertise, but business architecture can vary from industry to industry Therefore, I can see where this level of specialization would be valuable for the architect's remaining 20%. It's analogous to going to College Business School. Most of your classes are the core curriculm-- Marketing, Legal, Finance, etc. However, once you choose your degree specialization, there are specific skills you obtain that other specializations don't. Depending on which industry you work in (Government, Telecom, Retail, Manufacturing, etc) you could obtain EA specialization in that area. We can already witness this in the job recruiting space. Candidates are often courted and targeted for their industry background, just as much as their architecture background.

  • Fortunately, the human body has been architected by the highly-qualified “enterprise” architect. So the specialization on parts of it works. Unfortunately, we are dealing primarily with often-non-architectured systems (and systems of systems). So, it is highly desirable to have somebody who overlooks the whole (ideally with a proper team around that person). I think this is a way to reach the synergy between parts of your system (see the last paragraphs of the post http://improving-bpm-systems.blogspot.com/2011/07/enterprise-patterns-caps.html ).


  • The fact is, most EA programs are already highly dependent upon specialists. Either these domain specialists are centralized into a good-sized central EA team or they are distributed throughout the organization and formally tapped for contributions to coordinated EA efforts. This virtualized EA team is the reality for all the organizations that just can’t justify a big central EA team.

    What’s just starting to happen is that whole domains of the EA practice are being broken off and moved into different areas of the org chart, such as business architecture reporting into a business strategy exec and data architecture moving under a Chief Risk Officer. There’s some really positive impact here as we’re seeing the business side take an active interest in viewing the enterprise as a whole and getting serious about detailed strategic planning. But there is also the potential for new factions and new silos as EA starts to change form.

    I predicted in my February 2011 Forrester EA Forum keynote that not only will the business architecture function move into the business but by the end of the decade we’ll see the EA function move into the business, with IT or technical architecture staying in IT. There will be lots of ways for organizations to shoot themselves in the foot with these kinds of changes for all the reasons JP states. But I think there is tremendous benefit in not only engaging the business but getting in business ownership. The key factor: there must be someone explicitly in the EA role who actively connects the dots. I’ve seen an early version of a factionalized EA team, where the EA team is a virtual composite of these split-off areas — it’s too early to declare success or failure but I’m leery of any structure without an explicit EA role to drive the unification of the (needed) specialty areas. I think it’s fine if that role lives on the business side and other parts of the architecture team are in IT. EA has always been about unifying disparate views; formally placing areas of specialty into different parts of the organization is an evolutionary step that can have powerful impact — because it means others besides EAs will have skin in the strategy and sustainability game.

    Gene Leganza is a vice president and principal analyst at Forrester Research where he serves Enterprise Architecture Professionals.

  • Enterprise Architecture should focus on the whole rather than the parts. Knowledge of business priorities and strategies is important, and it seems to me that this is where most EA initiatives struggle. Therefore an increased business involvement, even business ownership, seems like a good idea. Specialists that EAs can refer to and work with already exists (information architects, business architects, solution architects, technical architects etc). Even if we want to add more such specialists I do not think this should be thought of as splitting up EA into different fields. If we do split up EA we will lose the heart and soul of EA – a clear view of the big picture.

    (I think both JP Morgenthal and Gene Leganza make good points above)

  • Even with architects who bear specialities in particular segments of an EA one still needs the type of EA that can tie it all together. The lack of alignment and coordination can lead to "poor overall patient care". Coming from a healthcare background the lack of a "primary care physician" can lead to contradictory diagnoses and prescriptions for a patient. leading to reduced efficacy and even death. The same carries over to the EA world. Sure, go ahead and specialize but you still need someone preserving the cohesiveness of the design (Fred Brooks?)

  • I really enjoy Nicks’ blog, but pa-leeeeese not another metaphor, EA is just like city planning, EA is just like physical building architecture, now EA is just like medicine???? Oh, yeah and moving the function out of the IT shop all wrapped together in one post! I don’t normally post on blogs because I’m overwhelmed by EAing, but frankly I’m annoyed by the current “EA is a failure” meme. So something like ½ of all “crummy” little system development projects fail but we’re surprised that trying to document, rationalize and transform systems of an entire enterprise "fails"? Like the others I disagree with his point, I don't know what his environment is like but I usually see what he described already, disconnected Data Architects, Biz Analysts/Architects etc.

    I agree that there are different schools of thought, mostly based on background, aptitude and education. The major problem IMO too few EAs have come up and paid their dues as solutions/systems architects, EA is a systems problem to me (like the Dr. Brooks reference BTW conceptual integrity = EA). The majority of "EAs" claiming there is something wrong with EA appear to be EAs with a business or consulting background, in the federal space they probably make up 80% of "EAs". Referencing Nicks post, should there be Strategy, Process, Business “Architects”, should EA be driven and align with the business and all the other Kumbaya? Yes, Yes and Yes. The biggest problem however IMO in EA is that a proper business architecture is never (in my recent experience) produced by the Business Architects. Business architecture is not a bunch of process diagrams at various levels of granularity, that don’t integrate with process diagrams from other projects, technology assertions from people who are not technologists, rationale for why they couldn’t instill some discipline on the business people and get requirements (moving too fast, agile LOL), some feelings, the biz architects new friendship with the business people, and a date when we should be “done”. If one looks at the TOGAF, FEA(F) or any of the others, you would expect high level requirements, performance/success measures, principles/quality attributes, high level concept documentation/agreements, Conceptual Information Models/Information Classification, Functional/Capability Decomposition (Are you doing AP, CRM or what?), As-is and To-Be Process models, Roles etc. before the PMPs say it’s time to start coding “agile”.

Add a Reply

Recently Commented On

Monthly Archives