InfoQ Homepage Presentations Questions for an Enterprise Architect
Questions for an Enterprise Architect
48:23
Summary
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
Bio
Erik Dörnenburg is the Head of Technology Europe at ThoughtWorks where he helps clients with the design and implementation of enterprise software. Throughout his career he has been an advocate of Agile values and Open Source software. Erik is member of GOTO Aarhus Program Advisory Board. See what Erik says on his blog: erik.doernenburg.com. Twitter:@erikdoe
About the conference
GOTO Aarhus is the enterprise software development conference designed for team leads, architects, and project management and is organized by developers, for developers. As software developers and architects ourselves, we wanted to craft the ultimate conference. The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community, staged in an intimate environment needed to support as much learning and networking as possible.http://gotocon.com/
Feb 03, 2012
-
Related Sponsored Content
-
Related Sponsor
/filters:no_upscale()/sponsorship/topic/2c0d72d2-1768-47c2-8f5b-24f3ef0ae0e0/QconNYrsb-1679560094156.png)
Community comments
Excellent talk
by Shadid Chowdhury,
Re: Excellent talk
by Eric Newcomer,
Re: Excellent talk
by Shadid Chowdhury,
Re: Excellent talk
by Eric Newcomer,
Re: Excellent talk
by Shadid Chowdhury,
Re: Excellent talk
by Eric Newcomer,
Re: Excellent talk
by Erik Doernenburg,
Re: Excellent talk
by Eric Newcomer,
Re: Excellent talk
by Erik Doernenburg,
Re: Excellent talk
by Zubin Wadia,
Good
by raj n,
Excellent talk
by Shadid Chowdhury,
Your message is awaiting moderation. Thank you for participating in the discussion.
Excellent talk! Makes a lot of sense.
Re: Excellent talk
by Eric Newcomer,
Your message is awaiting moderation. Thank you for participating in the discussion.
I found it disappointing. I don't agree with the characterization of the metaphors. Enterprise architects do not produce building specifications, they are more like the building code definers and enforcers. They do not specify where the wires go, but rather the type of wire that must be used.
Erik takes the developers' side too much - it seems his view is that developers should be free from enterprise architecture oversight. But this is contradictory to the goals of enterprise architecture, which is responsible for ensuring the priorities of the enterprise take precedence over the individual preferences of the developers. I realize this can be disappointing for developers, but it is necessary for large IT shops, especially today, where architectural practices are more important than new technology for the cost-efficient application of computer automation to business operation.
Erik is right about one important point however, which is that the architecture of the business needs to be understood and formalized in order to have a really effective IT architecture. Thus the emergence and importance of Business Architecture.
Re: Excellent talk
by Shadid Chowdhury,
Your message is awaiting moderation. Thank you for participating in the discussion.
@Eric Newcomer
I guess the metaphor,is more to say that Software Architects can't go into that much detail level as building architects can and also software evolves like a city both interms of how it is developed and how it is used. About your example of enterprise architects specifying what types of wires must be used is more like providing a silver bullet solution. In a real enterprise it is usually hard to standardize business units; thus saying what types of wire should be used creates more of a problem rather than a solution. But recommending different types of wires for different situations can be useful to developers. Again, it all depends what problem you are solving and how much you can standardize your solution domain.
An enterprise system can only reach it's goal when sub-systems achieve their specific goal. Liberty and usage of appropriate tool not necessarily means there will be a priority conflict. So, what you need is collaboration rather than imposing strict constrains on enterpise level.
Re: Excellent talk
by Eric Newcomer,
Your message is awaiting moderation. Thank you for participating in the discussion.
That's a nice idea, but it doesn't work out well in practice. The issue is not developer freedom but the enterprise cost. Allowing everyone to choose their own solutions and then federate via integration is a nice idea, and can be helpful when trying to help a complex legacy environment evolve, but it isn't a practice that makes sense if standardization is possible. Each development project incurs not only initial cost but ongoing expense odd support and maintenance. I know developers often don't like oversight and governance but it's often the only way to ensure the costs of IT are in line with its benefits to the business.
Re: Excellent talk
by Shadid Chowdhury,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think the point here is not about setting every developer free to their own choice, rather if you have an enterprise system that tries to solve diverse problem then you would like to allow the right tool set to be used for those problems. I would rather say by not doing so, you might reduce little infrastructure and operational cost but you will end up incurring much more cost in other areas. At the end of the day, goal is to increase profits. If your cost reduction starts shrinking the profit in long run then I am not sure this something anyone wants!
Re: Excellent talk
by Eric Newcomer,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm sorry if it wasn't clear. Of course we want to have the right tool for the job. We just don't want to have two that do the same thing. t
Re: Excellent talk
by Erik Doernenburg,
Your message is awaiting moderation. Thank you for participating in the discussion.
My point is that standardisation should only be pursued when necessary, not when merely possible. Everything has a cost, and so does standardisation.
Organisations that focus first and foremost on operational excellence are often quick to show how much money was / can be saved by standardisation. However, in such organisations it is often not tracked what hidden costs were introduced elsewhere in the organisation because of the standardisation effort. Think of the database example. Yes, standardising on a single database technology will likely reduce license cost, but having to switch database technology will hurt line of business development teams. That cost is often hard to quantify and, consequently, not tracked, never mind weighed up against the savings.
Focussing on standardisation can mean lost opportunity because when everybody is busy standardising, opportunities that require variation and individual optimisation are missed. This is why I open the talk with the four quadrant model, to show that wide standardisation only makes sense in certain situations. In other situations something else should be priority.
In this context it might make sense to consider the "you build it, you run it" philosophy that is popular with the likes of Amazon and Google. This article is quite insightful: queue.acm.org/detail.cfm?id=1142065
Hope this makes it a bit clearer. If not, I'm happy to try again.
Re: Excellent talk
by Eric Newcomer,
Your message is awaiting moderation. Thank you for participating in the discussion.
Not sure why you think it might be clearer the second time. I understand, I just don't agree.
Claiming that not standardizing saves money is pretty much opposite the case. It's like saying the exception is the rule. Of course there are always exceptions and we allow for them. But we don't base our plans on them, and they do not help save money. Standardization does.
What Jim and Werner are talking about is exactly what we are doing, and it won't work without standards. As the rule, not the exception.
What we are dealing with, as most companies with legacy environments are, is:
www.laputan.org/mud/
This is what you get without architectural oversight, including standards. In particular refer to the shantytown analogy, which is what happens when developers just do what they want for design, technology, tools, etc.
The disappointing part of the talk is the idea that somehow there's a valid compromise between developers and enterprise architects. Enterprise architecture is there to provide discipline for the developers, who typically prefer to be heroes than consider the best interests of the enterprise. See Jeanne Ross's views on the subject here:
blog.opengroup.org/2012/01/11/mits-ross-on-how-...
This talk took the developer side too much in my view, and did not recognize enough the reasons why we do enterprise architecture. The purpose is not to annoy developers. The reason is that at this point in the maturity of the IT industry, architecture (and discipline) is more important than technology. Developers may not appreciate that very much, but it is nonetheless critical to a successful IT department in a competitive business.
Re: Excellent talk
by Erik Doernenburg,
Your message is awaiting moderation. Thank you for participating in the discussion.
Interesting. You say you do exactly what Werner is talking about, which means we must be in agreement somehow, because I agree with his points; especially this one:
"Each service has a team associated with it, and that team is completely responsible for the service—from scoping out the functionality, to architecting it, to building it, and operating it."
This leaves, in my humble opinion, little room for a central team of enterprise architects that provides "discipline" to the service team. But maybe both of us interpret what we read to confirm our own opinion (confirmation bias).
To try a concrete example. Think of a financial services company. They have one group that deals with wealth management and another group that deals with credit cards. The customers could be shared. One of the groups, and I am specifically including legacy scenarios, has implemented their app in C# storing data in MS SQL Server. The other group has written the app in Java storing data in Oracle. The second group has determined that a switch to MongoDB would make sense for them, proper ROI case. In this scenario, what standardisation would an enterprise architecture team promote? Or is this one of the exceptions you refer to?
Different example. A system has a web facing app, which needs to scale horizontally, and an inward facing admin app, which requires a richer interface with workflows. Would an enterprise architect stipulate that the app architecture has to be standardised? Would it be possible for the web facing app to use a simple templating framework while the inward facing app could use a component frameework? Where does the standardisation end? Who is best positioned to make these choices?
Good
by raj n,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks Erik - enjoyed the talk. I thought it was very practical.
Re: Excellent talk
by Zubin Wadia,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't mean to go all peace pipe here, but both EricD and EricN have valid points.
Amazon does standardize by making sure every technology initiative they undertake works within a service interoperability framework. All their production implementations need to expose service interfaces; they all need to be discoverable, and they all need to be atomic so that they don't being down other services in the coordination chain. This forcing function in some sense IS standardization regardless of the fact that different teams, with different architects and even different languages are involved.
So there is diversity and homogeneity being cultivated here. Facebook takes on a similar approach with Thrift. As for the whole OracleDB or Mongo question, they are not the same thing. You might need one or both but not for the same use-cases. Standardizing on Oracle XMLDB vs. Couch vs. Mongo might be a more pertinent example. Even between those three we have CAP trade-offs that need to be evaluated against the mission profile.
Speaking of mission profiles - there's a huge difference between organizations with mature operating profiles and ones attempting to change the world. Mature organizations tend to have broader technology footprints but don't have use-cases that push their stacks to the limit. "Change the world" organizations with momentum tend to have extremely focused missions and usually push their stack to the limit. Different worlds with different tolerance levels. And with everything there are exceptions to the rule (algorithmic trading platforms and such).
Cheers,
Zubin.