I will be speaking in The Enterprise Architecture Conference 2006 to be held in Singapore on 25-28 September 2006.

And no - for once, I wont be speaking on Web Services or anything Service-Oriented. Instead, I will tackle head-on a topic that not many people would not like to go near: Enterprise Architecture Security

I will be speaking on the second day (27 Sept 2006: 1430-1530) and quite a few of my governmental clients will be there as well in the audience.

The title is: Security Planning and Strategies In An Enterprise Architecture. The agenda is as follows:

• Outline of the key Enterprise-based security issues and counter-measures, that is technology-agnostic
• An examination of general security threats and how to plan and implement security policies and controls for often-performed computer security activities
• Key best practices in terms of security that can be applied to practical real-life scenarios and implemented solutions such as IP and Data security
• Auditing and monitoring of systems within an Enterprise

If you are in need to spend SGD2,000 , I hope to see you there.

One of the topics presented during the Architecture Track in the just-concluded Microsoft TechED South East Asia 2006 was done by IASA.

It was done via a very interactive session with the floor questioning the panel from the IASA Malaysian chapter about the value of being an architect and topics of the like.

One of the questions from the floor was: "Do you believe that architects should be writing code ?"

It seems that 3/4 of the panel members agree. Some even going on bragging that he is still doing it in assembly, C++ language. hmmm ... In the interest of keeping the session on time so that that the attendees can get home on time amidst the KL jams - I kept my mouth shut.

Let me open them now.

Architects shouldnt code. Period. My thoughts. Period. To prevent myself from rambling, which is what I always do when I have a strong opinion on something, let me list them in point forms.

The term "architect" is a very nebulous term. The hype around it with all the wannabees printing it in bold font on their cards out there (I know a couple of them in Singapore who does them with no shame), who have no idea what is the difference between horizontal and vertical scaling, doesnt make it any better. For better or worse, I only believe in one type - and that is the all-emcompassing solution architect.

Afterall, aint what all customers want is a solution ? Do you think they really care what is underneath the solution more than that this solution works well, is kept within their budget, perform effectively and efficiently within the constraints of their environment ? Therefore, in this context, I will speak in the context of Solution Architects.

• To those ppl who said that "How can someone who never writes a line of code be responsible for how that code will be written? ", again, I am talking about a solution architect. In any case, an architect can code, sing, dance before, for all I care. They shouldnt be doing it in their role as solution architects now. Read on.

• In the past, code influenced architecture. The limitations of written-code in a chosen-platform in a defined-era is the damning evidence of the limitation of the architecture. VB3 anyone ?

• Biasedness based on preference. A solution architect that has a decade long experience in writing code is usually one that doesnt see the other side of the fence, doesnt know that there are better solutions and worst - refuse to want to see it. Most of the people in this category are usually skilled in one platform over the other and it is very hard for people like that to sit down and analyze a problem without a pre-conceived notion in mind in a very neutral manner. Because of this, the likely solution they are going to propose will have the same limitations of the platform they have been so comfortable with. I dont question the depth. Where is the breadth ? These guys should remain what they are good in and be experts in their domains and probably be paid better than a solution architect. For those who argue that they are equally well-versed in both sides of the fence - Good for you. Stay there. It is very likely you are drawing a lot more than an architect. If you are not, you just need to sell yourself better.

• It is all about the business. Solution Architects bridge the gap between (the returns of) the business with the (returns of) technology. So, yes, they should be just as apt with the Finanical Calculator as much as an Integrated Development Environment or a Installation Panel or Console. They understand the entire depreciation cycle of an enterprise solution much better than the differences between a thread and a process. So yes, the higher the level the language they used to code in (I am talking about 4GL), the better. Bragging how much you still do your work today in First or Second Level Programming Lanaguages doesnt do you any good. In fact, it makes you look bad. It shows the lack of touch you have with your business, how it is run, what are the constraints and the entire business and revenue model. Writing performance drivers, assemblers, kernels, runtimes has nothing to do with a company's business model in a world where Moore's Law still rules.

It is all about the business, still.

Now if XML-RPC aint enough (I had blogged about this here and here), now we can add REST-RPC into the mix. The main difference would be the use of HTTP to provide application semantics via its verbs. This would mean that there would hardly be any XML or Request payload of any kind.

In an article on eweek, John deVadoss, director, architecture strategy at MSFT Corp made the following quotes:

[QUOTE]

The consumer edge is the peer-to-peer, Web 2.0 world and the enterprise edge is the SOA, ESB (enterprise service bus) model. In addition, the consumer edge is an asynchronous communications model based on the REST (Representational State Transfer) scheme, and the enterprise edge is based on the Simple Object Access Protocol scheme.

 "REST is a dominant model on the consumer side, and SOAP is the model on the enterprise side," deVadoss said

I know many people would probably shake their heads now as to the confusion that has arose with this quote. Actually, while I couldnt quite fully agree with everything said above - the nugget to dig here is that one resides on the edge of the enterprise (or the high-end processing machines out there) and the other resides at the side of the consumer.

In reality though, what ultimately serves the consumer are the enterprises, in some way or another. It is the consumer who pays - no ? Therefore it would be safe to assume that there is a mixture of both schemes in any enterprise.

While SOAP is probably familiar to many, REST shouldnt be a stranger to many more. It is nothing but how the World Wide Web has been working. It just has a new label OR should I say be saying that the label is stickier now ? SOAP and all the XML acronyms has just emphasized it more. While you may not need to know the URIs, URLs and the way resource locators work or how it came about - you may need to know the word POX (Plain Old XML).

In simplistic terms - POX is just XML that doesnt really have a defined structure. In contextual terms, POX is XML that is not SOAP.

Makes more sense now ?

On the back of this, from Paul Fallon's space here, Max Feingold has a real good summary on Whats New with WS-AT, WS-BA and WS-C.

Should make for some good reading on my looooooooong flight to LAX via the Pacific Route.

According to Don's blog here: Indigo has support for REST since Day 1. In the same breadth, he disclosed that it will explicitly support HTTP PUT/POST/DELETE/GET to please the REST purists out there.

Like Steve mentioned here, I, too, am not a fan of technology stacks that complete with their own ideologies. To me, technology is there just to get a job done efficiently and effectively. My post here attracted quite a fair bit of hits and same-echo-sentiment emails. It even made to ZiffDavis blog list here.

As Steve has echoed as well, I am also even more convinced now that Indigo is going to be the platform to beat when it comes to distributed communications. No doubt about it.

I am really glad that the Indigo team, whom I think comprises some of the brightest minds in the software field, is all united to work towards a common goal of creating a religion and ideology-agnostic product. If this is not innovation, I dont know what is.

Show me the money, Beta1

I have been invited by the Ark Group to speak in one of their major technology management conferences in Singapore on the 27th July 2005.

This conference is themed around Planning and Implementing Service-Oriented Architecture : Developing SOA to Reduce the Cost of Integration, Leverage Legacy Systems and Improve Business Agility.

My 45-min presentation is titled:

Design and Security Notes from the Field

• Distributed Computing
  • Thoughts
  • When to use What
  • More Thoughts
• Distributed Security
  • Thoughts
  • When to use What
  • More Thoughts

As usual to my presentation style, I tend to keep my topics interesting and a refreshing experience. The conferences in this field has always been dominated by the academics, researchers and technology vendors who sometimes lose touch of whats happening on the ground. I will go against this bias and inject some field experience in there. It should be an interesting conference for attendees and delegates. I think it will even be much more interesting when I sit down with them for networking lunch.

I hope to see you there.

I have been following the exchanges between Savas, Jim Webber, and Michi Henning here and here. There are more links but I will leave it up to the interested reader to use a RESTful approach to refer to those resources from the above 2 links.

To be honest, this has been piped over the newsgroups, forums, conferences, etc for some time now and it is really nothing interesting to debate about, really.

All this noise has led to a lot of FUD in the field and I get a constant barrage of questions in any of the technology conferences I speak in or attend. I work in the fields out there and therefore I tend to approach technology unlike that of academics, trainers or vendors. I do what clients want in the most efficient way (read:cost_and_resource-effective) possible. I have met a few people from academics as well as from the product vendors who entered the field thinking that just because they can point out which exact page number explains the ds:SignedInfo in _WS-Security Specs_, they can convince and conquer the field and have every single customer out there upgrade their existing technological infrastructure every 6 years.

Well, the Mainfraimes, the CICS and the COBOL wonks are still out there. Still making a lot of money for its vendors and service providers. People are still driving Ladas and these legacy will be there for some time, probably a long long time.

We get a lot of younER developers who are very confused with all barrage of technologies out there and sometimes people on the field (which means customers as well) get the short end of the stick when these developers use the wrong technology in the different parts of the technical solution. So, yes, some of the stuff you read in the Daily WTF is not ficticious.

Sometimes, when I come across comments like these here from Savas's blog here:

> Microsoft is betting on SOAP and made it a key part of its distributed computing platform, not DCOM.

Betting on SOAP? Hmmm... .NET remoting does not use SOAP. It uses a binary protocol for performance reasons. So, I'm not sure that Microsoft are "betting on SOAP". They certainly are not for their .NET remoting protocol. And DCOM failed because it could not be made to scale, due to its misguided garbage collection idea. And because DCOM, amazing as that may sound, was even more complex than CORBA.

Somehow, I either feel that I still dont get the picture or that irrationality is clouding good judgement (still).

Of course, .NET Remoting doesnt use SOAP. In fact, it used to and is deprecated for good reasons. It is a distributed object technology which implies implicit method invocation. SOAP is not a distributed object technology. It is all about services, all about standard schemas, being explicit in design and yes, it also means dispatching these XML documents on a "hopeless transport" or the Lada of the network protocol today. You cannot compare them just like you cannot compare the performance of objects and services.

Is this the best we can do ? Of course NOT. Should we all dump our existing heap of scrap metal in our garage and get the shiniest and fastest aluminium today ? Of course. Are we going to empty our bank account, forfeit and compensate on our current loan arrangments to do it ? NO, NOPE, NADA ... This is a just a fact that we have to deal with.

Having said that, to me, both sets of distributed technologies will have its place to stay, regardless of what the vendors say to sell more and the trainers sell to teach more. Each have its place and their merits tend to show up best if used and deployed wisely in the different layers, tiers and boundaries of a decent, usable and viable solution. When I say Solution, I mean an entire composition of different new and old systems that services a business program, initiative and ultimately a goal. Isnt that what we are building systems for in the first place or have I totally lost my mind and lost track of who my paymaster is ? Dont get me wrong, progress is not possible without making full proof and implementations of the latest rocket science or theories. But Progress can be measured in many ways. To most people, progress is measured by how they can make legacy or existing technologies and architetures last and endure given the rapidly evolving set of standards, protocols and environments and how fast they can go home and spend time with their families as age increases and TTL declines.

COM+, DCOM, .NET Remoting is something we use very frequently on the field, and for good reasons too. I am known to be a (W3C) SOAP Wonk BUT I will not give them up easily within the innards of my system and I will use SOAP for the reasons it was designed for. In fact, to me, one of the most important features in SOAP is the @role (@actor) and the @mustUnderstand. Or else, I would just stick with just plain old XML.

Is Microsoft betting on SOAP ? You bet, and so is the entire industry. It is a well known fact that while it is simplistic in design (in fact, this is one of the wierd specification that becomes simpler as the newer iteration evolve. Let hope it remains this way), getting across-the-board agreement is the costly element. In fact, it took 5 years from the original design meeting and prototype to become an “official” specification and it (SOAP 1.1) is still not an official W3C Submission. The cost to each participating organization easily crosses several million USD. The rough estimates to putting the final WS-* specs to bed (if there is such a thing) would easily be more than 20 million USD.

Just like life, in the field of software engineering, compromise is something we need to work with. I once had a straight-through exhaust pipe the circumference of a toilet bowl fitted underneath my car as well as a wide-open air filter underneath the car bonnet. After 3 months, I couldnt deal with the generated noise as well as the (less-dense) hot air the air cone was taking in from all angles so I dumped both of them. While it may take me slightly longer (by a few seconds, perhaps) to reach the market to buy groceries, the brat in the younger me learnt to deal with it.

While, I have my own ideas on the Request/Reply MEP, RPC, Document-Literal Messaging, etc and I like to share my research and thoughts with some of the brightest minds in the industry over a hot cup of Java, it is not something I lose sleep or sweat about. It just serves to keep my sanity in check when I still have to deal with OLE and VB3 issues today and it does make good conversation with some of the most intelligent geeks out there.

Sometimes, I feel the point of technology is lost when people argue over stuff like that. To these people, I recommend a good classic read: Technopoly: The surrender of Culture to Technology by Neil Postman