That which I described a month back relates to an application called payments, and a variation designed to make it better. One aspect that probably rankles is that a lot of people in the so-called Architecture role do something else, and that's not it
This is what is killing Enterprise Architecture… every computer programmer, systems designer, software architect, solutions architect, technology architect, computer operator, PC owner, data architect, database architect, network architect, business analyst, systems analyst, enterprise architect, service architect, object architect, project manager and CIO calls whatever they want to or maybe, whatever they are doing, “Architecture.” It is chaos. No wonder we don’t have Enterprises that are coherent, integrated, flexible, dynamic, interoperable, reusable, aligned, lean and mean and working.
So sayeth John Zachman, who is credited with having invented a term or two in the space.
Here's one variation in the workspace of Architecture, which some call programming in the large. Consider the app from the last post, payments. It's cohesive, tight, and operates to a set of rules. It has strong boundaries. We can analogise this process to be like a building; hence it is probably fair to claim someone who designs and builds a payment system can call themselves an architect. If not fair, uncontroversial.
There are also many others applications, and each of them can be analogised to a building. They are each cohesive units, strict rules within and without, and they are generally focussed on particular purposes. For each building, we have different Architects, and for each style of building, we have different styles of Architecture.
Then, there are places where there are many applications. Larger companies, government departments, banks, etc, have dozens or hundreds of these applications. And, what's more, these applications are often connected in long, difficult transactions. A particular client's request might go wandering through from app to app, department to department, database to database until it finally pops out the other end.
This is a very different building process, it's a macroworld compared to the individual building's microworld. In order for the whole organisation to deliver on its goals, all of the apps and people must somehow play towards the same goal; which means we have to bring all these together somehow. Architects have to talk to Architects, apps to apps, people to people, and many variations.
It is tempting then to extend the application scenario and simply view an organisation as a very large application. But this runs into trouble very quickly. Firstly, all the individual apps run to their own timeline. Secondly, departments, and people, are jealous of their independence. Thirdly, the complexity is such that without very good oversight, very good understanding, and quite deft tuning and aligning, an Architect of an entire organisation will likely fail to make a mark.
In order to make all this work, and improve, we need to set some guidelines. Firstly, once delivered, applications do not change much, if at all. Just like we don't go moving buildings around just because they are now inconveniently placed. Secondly, the interconnections between the apps are capable of changing , and being re-used for new and diverse purposes. This is the streets and walkways between the buildings, which typically become public ownership; they always seem to be being dug up and moved around for one reason or another.
Hence we start to look at how the applications can look to each other, and we also start to standardise this as a first step. From this view comes the march of webservices, XML, WSDL, and friends: if all apps deliver their output in standardised forms, then it becomes a matter of cheap scripting for other apps to tap that output. Once that is done, we can start to re-connect, inter-connect and so forth. Hypothetically...
Which leads to the next issue. Although we've tackled ways to reconfigure the I/O of the business units, just like we used to reconnect computer peripherals with cat(1), and we've created a fast & flexible form of BPR, we still haven't reduced the complexity. For that, a wave of tools and methodologies has rushed in like a tsunami to try and map out the complexity in some fashion to allow our supreme leader to be the true master of all she surveys: service discovery, service cataloguing, service levels, dependency mapping, defect discovery, transaction troubleshooting, model-driven reconfiguration, use-case mapping for large transactions, etc etc. With the flood of tools comes the flotsam of buzzwords, jetsam of key phrases, and sales calls for yet more tools. Anyone in the business will tell you this is a very costly area, as every new tool promises far more than any other tool has ever delivered, and you only find out after paying the price that there is a new must-have tool just around the corner.
All of which goes to suggest that this is a very different game to Architecture. This is really City Planning, and although it is a sub-branch of what the Architecture Professionals like to consider their domain, it is a very separate field. An application Architect is very focussed on the tech, and needs to tear himself away from it to understand enough of the business in order to build something that is wanted. But in the wider organisation domain, the reverse is more true: this person is very focussed on the business, and she needs to tear herself away from the business just enough to understand what the tech can do for her, in the way of interfaces, data formats, etc.
Just like the Architect meets the City Planner at the boundary line, driveway and other pipes, the Application Architect meets the "Company Planner" at the external I/O interfaces of the App. The desire for every building to have the same boring driveway is seen in webservices, which can be considered to be a lowest common denominator of application driveway.
What then to call this person? Because the domain Architects grew out and upwards from this field, on the supremacy of their applications, they are sometimes called Enterprise Architects. But this is a parochial, bottom-up view by technologists, who press the case for more technological tools. We can also look at the question top-down, business oriented, and there, we find a familiar thread: we are talking about Business Process Re-engineering up in the early 1990s, and the rampant charge of the MBAs at that time, and then a stampede of competing methodologies from consultancy companies with different names, variations but one common theme: interconnecting the units of business in better and more efficient ways.
In the last decade, we saw the Enterprise Architecture approach possibly succeeding and outlasting, where others have not. However, it is not easy to attribute the success to its rightness; more likely it is attributable to the rise of the computer and information within modern service business. Enterprise Architecture rose upwards on the back of tech companies' assault on the business of business, and less so on its own merits.
All of these have something of a fad in them, but something of the truth. That old dirty word BPR was essentially what we wanted, but we want it to be done every week, not every decade. Every other buzz/fad/gee-whiz word like TQM, JIT, 6 Sigma, Lean, Business Transformation etc etc that followed (or led) tried to repair some of the gaps in the previous (or following) fad, but they all suffered their blind spots and their seduction to increasing complexity. Any recipe teachable to ordinary people in ordinary business fails to understand the whole complexity of business, it seems. Leaving plenty of room for the next fad...
Meanwhile, the MBAs had the ability to talk to all the departments in their language, understand the papers and draw the lines they wanted, dominate and improve on all the various methodologies ... but they didn't have the technical credibility to make it happen in a computer-driven world. (They would have loved Agile.)
The IT-focussed Architects have the latter, but not the former; they know how to program in the small with data and functions and objects. But when it comes to programming in the large, with people and customers and processes and refunds and laws and giveaways and expediting and sickleave and and and, not only is their experience simply lacking, but the rules of programming are completely different.
Which all leads to what, exactly? Although I think some very good stuff is happening in the Enterprise Architecture world, I also sense the mismatch in viewpoints. To me, I get the feeling that this evolutionary game isn't over, there's a few more cycles before we figure out who is the real master of the high-density information city. It is like we are back in the 1970s, admiring the traffic jams and the smog in Los Angeles, thinking that all this activity means we're on the right track.
We know that Cities have City Planners, and it is a distinct discipline. We just haven't found, named and understood the City Planner for information-driven business as yet. Right now, I feel we're back in last century, 50 years ago, Los Angeles: admiring the traffic jams and pile-ups, selling traffic lights, thinking the info-smog tells us we're on the right track, and complaining that City Hall is digging up the streets. Again :-(
(Hattip to Martin Bramwell who provided much of the helicopter view for this essay!)
Posted by iang at August 5, 2010 12:48 PM | TrackBackIan,
Hat tip appreciated. Thanks!
I'd like to modify a few of your remarks, though, nonetheless.
"... once delivered, applications do not change much, if at all. Just like we don't go moving buildings around just because they are now inconveniently placed."
I think you are letting the analogy lead you astray here. The fact is applications MUST and do evolve. Meanwhile data, or more specifically data structures, change hardly at all. Enterprise Java Beans (EJBs) were an attempt to incarnate this realization. SOA (Service Oriented Architecture) was another.
Both of those seem to be giving way to REST style data presentation, where SQL is tossed out in favor of a return to hierarchical data. Couple that with the Semantic Web, that binds REST style data to semantic schema, and the entire idea of an application disappears into the mists of time.
In such an environment “Programming In The Large” becomes all important. “Mash Ups” are one tool in vogue for doing that. BPEL is another. Generated from a BPMN diagram, it allows access to data by different users to be structured into business processes with a very high degree of agility. To continue with the Urban Planning example, BPM would be analogous to the expediting orders at UPS or FedEx. The drivers and package handlers have no idea of the contents, but they pick them up, pass them from one to another and drop them off, on every kind of “driveway” there may be, even purposely distributed drop boxes.
So I beg to differ when you say, “There are also many others applications, and each of them can be analogised to a building”. It would be much more accurately representative to say, “There are also many data structures, and each of them can be analogised to a building”.
To go further, you say, “It is tempting then to extend the application scenario and simply view an organisation as a very large application.”, but not one of your three arguments against that is very convincing. They all say, in effect, “Accept institutional rigidity”. Management may surrender to that, but the market will not. Excessively rigid institutions go under. M & A activities subject applications to tidal forces that break them up into fragments.
So to summarize, and to risk the impudence of paraphrasing you, “There is only one application and it is the Internet.” The only clearly discrete units in that vision having any kind of durability are the Data Element and the Use Case. We need to grow out of the bad habit of binding them into “applications”.
Hasan
I assume you are looking down from 20,000ft with your view, and thus miss out on what is at ground level and below?
Below the streets is where the "services" are all the basic utilities (gas, water, electricity, sewers) but also communications that transport information and occasionaly (in large city areas) people via the metro etc.
It is these that the city planner is most woried about not what goes on at ground level and above. And invariably architects don't conciously think about them in their designs they just assume they will be available in the required capacity as required.
And it is at this almost unseen interface that most things go wrong. After all your local metro is not going to be happy if the foundation auger just drills into one of it's tunnels likewise the neighbours are not going to be to impressed when the lights go out or sewerage backs up through their toilets or onto the streets or god forbid a gas main ruptures and causes an explosion that causes death and destruction.
It is this non apreciation of the "not immediatly visable" where most "information architecture" goes badly wrong. Architects are more artist than engineer (they try not to sully their lilly white hands with what they see as blue collar work) where as city planners realy do have to be full on engineers with many disciplines under their belt and they tend to call themselves "Civil Engineers" with good justification.
I don't know about you or the rest of your readers but I suspect they are going to say "Ahh yes" we had a major issue with System / Enterprise Architects making assumptions about the "not immediatly visable" and that's what we need ICT "Civil Engineers" to keep the Bl**dy Archtects feet on the ground.
However your "Street view" does have an interesting analogy with Google and security.
Most are aware that Google have little cars driving up and down every road taking photos of people on the walkways (there's one of me with my middle finger up at one, on the web if you want to find it ;) and peoples homes with their cars in the drive way etc.
Now this wonderful source of information is just what burglars and car thieves need. This has become such an issue that some legislators are trying to push through legislation to add 5 or more years to a persons sentence if it can be shown they used "street viewing" information from the Web...
The problem with the "street view" of Information Architecture is thos little camera cars or "service discovery" systems. All applications have weaknesses and just dumping them on some Enterprise Highway connected to the rest of the road system with no let or hinderance is just asking for trouble.
The thing is as architecture most applications dont have doors or windows or even walls just random holes through which anyone may pass if they know where one is. Primarily because when the applications where designed the System Architects behaved more like "decorators" and decided to concentrate on the "office decor" not the "protection from the external environment" they "just assumed" it was there provided by some other Architect...
In short most applications do not have sufficient security built in to be "opened up" to "everyday traffic" let alone naredowells with an eye for oportunity. And trying to is only going to lead to a world full of hurt.
What the Enterprise Architects need to do is differentiate between the infrestructure, building fabric and office contents 9which they appear congenitaly incapable of doing).
They then need to build new buildings correctly connected to the infrastructure above and below ground and move the office contents in then demolish the old buildings.
The problem is they are currently doomed to fail because there are no ICT "Civil Engineers" to help the Enterprise Architect put the building on solid foundations and correctly engage with the infrastructure. It is why so many big projects fail you cann't build castles on clouds, you need solid foundations on mountains to put them in the clouds, but for them to work you have to secure your "services" otherwise your castle will not be habitable etc.
Importantly though time has moved on and Castles are not even "so last century" the design of secure modern buildings is very much the same as prisons and it is that our Enterprise Architects should be looking at for inspiration.
Posted by: Clive Robinson at August 8, 2010 02:48 AM