Jeff Schneider has a blog post entitled You're so Enterprise... which is meant to be a response to a post I wrote entitled
My Website is Bigger Than Your Enterprise.
Since he neither linked to my post nor did he mention my full name,
it's actually a coincidence I ever found his post. Anyway, he writes
In regard to the comment that Dare had made, "If you are building distributed
applications for your business, you really need to ask yourself what is so
complex about the problems that you have to solve that makes it require more
complex solutions than those that are working on a global scale on the World
Wide Web today." I tried to have a conversation with several architects on this
subject and we immediately ran into a problem. We were trying to compare and
contrast a typical enterprise application with one like Microsoft Live. Not
knowing the MS Live architecture we attempted to 'best guess' what it might look
like:
- An advanced presentation layer, probably with an advance portal
mechanism
- Some kind of mechanism to facilitate internationalization
- A highly scalable 'logic layer'
- A responsive data store (cached, but probably not transactional)
- A traditional row of web servers / maybe Akamai thing thrown in
- Some sort of user authentication / access control mechanism
- A load balancing mechanism
- Some kind of federated token mechanism to other MS properties
- An outward facing API
- Some information was syndicated via RSS
- The bulk of the code was done is some OO language like Java or C#
- Modularity and encapsulation was encouraged; loose coupling when
appropriate
- Some kind of systems management and monitoring
- Assuming that we are capturing any sensitive information, an on the wire
encryption mechanism
- We guessed that many of the technologies that the team used were dictated to
them: Let's just say they didn't use Java and BEA AquaLogic.
- We also guessed that some of the typical stuff didn't make their
requirements list (regulatory & compliance issues, interfacing with CICS,
TPF, etc., interfacing with batch systems, interfacing with CORBA or DCE, hot
swapping business rules, guaranteed SLA's, ability to monitor state of a
business process, etc.)
At the end of the day - we were
scratching our heads. We DON'T know the MS Live architecture - but we've got a
pretty good guess on what it looks like - and ya know what? According to our
mocked up version, it looked like all of our 'Enterprise Crap'.
So, in
response to Dare's question of what is so much more complex about 'enterprise'
over 'web', our response was "not much, the usual compliance and legacy stuff".
However, we now pose a new question to Dare:
What is so much more simple about your architecture than
ours?
Actually, a lot of the stuff he talks about with regards to SLAs,
monitoring business processes and regulatory issues are all things we
face as part of building Windows Live. However it seems Jeff missed my
point. The point is that folks building systems in places like
Yahoo, Amazon and Windows Live are building systems that have to solve
problems that are at the minimum just as complex as those of
your average medium sized to large scale business. From his post, Jeff seems to agree with this core assertion. Yet people at
these companies are embracing approaches such as RESTful web services
and using scripting languages which are both often dissed as not being enterprise by complexity enterprise architects.
Just because a problem seems complex doesn't mean it needs a complex technology to solve it. For example, at its core RSS solves the same problem as WS-Eventing.
I can describe all sorts of scenarios where RSS falls down and
WS-Eventing does not. However RSS is good enough for a large number of
scenarios for a smidgeon of the complexity cost of WS-Eventing. Then
there are other examples where you have complex technologies like
WS-ReliableMessaging that add complexity to the mix but often don't
solve the real problems facing large scale services today. See my post More on Pragmatism and Web Services for my issues with WS-ReliableMessaging.
My point remains the same. Complex problems do not necessarily translate to requiring complex solutions.
Question everything.