Questions for an Enterprise Architect
Recorded at:
- Share
-
- |
Read later
My Reading List
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
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.<a href="http://gotocon.com/">http://gotocon.com/</a>
Re: Excellent talk
by
Eric Newcomer
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
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
Re: Excellent talk
by
Shadid Chowdhury
Re: Excellent talk
by
Eric Newcomer
Re: Excellent talk
by
Erik Doernenburg
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
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
"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?
Re: Excellent talk
by
Zubin Wadia
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.
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think