António Cruz

In my first post about the subject, I've focused on what service orientation is not. In this second post, I'm writing about what I think service orientation really is:

1) Exposes business processes as services:

SO impacts vertically your organization, and may/should change the way you think about and develop software. You will be more and more focused on exposing every process in your organization as a service and not just developing single components. In your analysis/modeling phases, you'll think more about what candidates you have for being a service, your development process assembly line will give more attention to composition and integration of services and less to construction of components, and you'll have the need to ensure that every service you do is validated against best practices and registered somewhere so you can find it, whenever you need it. This means you'll need a well structured development process in order to be able to produce many small building blocks of directly reusable business assets.

2) Is standards-based:

While it is possible to implement services without thinking about standards, this does not means you should do it. SO is about standardization. Yes, this means you must not demand your outside consumers to understand and support your internal version of a markup language. You should keep it as an internal implementation detail and expose an adapter or facade with a standard interface to outside consumers. Also remember you don't know every possible use case a service can participate in the moment you deploy it. If you want to support unknown consumers, you'll be better implementing standards-based services. By the way, using a Schema-First or Contract-First approach can help a lot on this, as the basis for enforcing standardization best practices.

3) Provides cross-platform interoperability:

As a consequence of 2), interoperability will be achieved through SO practices. For example, as a C# programmer, the next time you'll need something from that Perl, Python, PHP or Java team, you'll know you can have it. Just ask for a service. Everyone will know what you are talking about: a reusable component with a standards-based interface and an address you can use to consume it. You can have your services consumed by any Windows, Linux or Macintosh client, and this means real cross-platform interoperability, not just interoperability between different versions of Windows.

4) Delivers a catalog of reusable services:

If you have more than half a dozen services, you'll need a services catalog. Note that if every service has about 8 operations in it, you'll have at least 48 operations to care about in those half a dozen services. Experience showed me that the number of services in a organization will grow fast in the adoption phase of SO because you'll want every aspect of your business reusable as a service can be. By the way, this catalog will be what you make of it. If you produce a services list and just maintain it to be able to find a service name or operation by its description or tagging, than you'll have a services directory. Or you can ask for more, and have registered in your catalog their dependencies of other services and applications in production, so you can develop a notifications system that will tell you what is affected, when a service is down. I don't think you'll achieve SO governance without having a catalog.

5) Basis of services central administration:

Using a service-oriented development process as mentioned and the catalog described in 4), you can mount a system that allows for central monitoring of resources involved. As I wrote in my previous post, SO is about transparency. You will tell everyone what is happening in every moment. How many Request-Per-Second every operation has, who's consuming it and what is the system health at any time. You'll need policies in place for that. Every time a service is deployed, you'll need to respect some registration procedures so you'll be better making these procedures part of your development process deployment phase. Don't poll your services for problems or you be a SO slave. Try instead to use your services catalog as the information basis you need to implement a pulling system that notifies responsible people.

6) Improves business agility:

Agility of business is SO promised land. That's why it is worth to do it. After being on the road to SO and starting to have a significant number of services, you'll start benefiting from them. For example, the next mobile project you'll have using some of those business process features you exposed, will be faster to implement, will be less expensive and will have greater quality than if you did it without using SO. Sapo Mobile project is a good example of this. After running SO for about a year, Sapo had enough registered services to be able to design, develop and deploy this project, in only about three months work of three focused people. This means that after reaching some maturity, SO adoption will deliver the agility you expect from it, not necessarily because you can make services faster than classic components, but because you are allowing business logic reuse in totally different contexts.

7) Gives strategic advantage to adopters:

Having the possibility to deliver new lines of business by composing services is very attractive to all business stakeholders. You will have what other competitors don't and that is why it is strategic to have it. The possibility of delivering a new business idea's value in a short time is crucial to be on the top. That said, keep in mind that beyond the LEGO pieces developers do, there is a greater value of SO. People will be using best practices to achieve common goals and, again, that is why SO is all about collaboration, not technology. After realizing SO value, if you try to change it for some other process, people will want to know why. This means the real value of SO is on the people who is doing it.

8) Has a great ROI:

All the previous will lead your business investments to a greater return. While it is obvious that SO adoption will have great costs, all efforts spent will come back through generation of business opportunity the organization could not reach before. You can realize this just after some months, if you carefully chose one critical but valuable business process for SO adoption. SO will pay for itself as it goes by, but you have to think of it as a on-going-best-practices-followed-by-people-process, or you make it dye. This means you have to follow up on its health, empowering the people who are in place of making it succeed and always keeping an eye on what next challenge will be made to SO.

These last 2 years as software architect and lead developer for Sapo Services project, I learned a lot about what is service orientation and what works better. These conclusions are of course taken from my real-world experience implementing this and other projects I take as an independent consultant and not a law you will see applied in every case. I will make a two-post series on this subject, also giving fundament for every argument I'll present.

I'll begin with what service-orientation is not:

1) It is not easier:

Service orientation is not easier to implement than a monolithic architecture, OOP or CBD. One big ball of anything is obviously easier to do, compared to many separated balls who communicate as a complex system. There are many industry best practices involved in a service orientation project and your knowledge of them is critical to success. You will need good communication skills with all stakeholders and to be specially disciplined as you drive them out of chaos.

2) Is is not faster:

Service orientation projects do not take less time to deliver than a classic .NET or Java project. Because applications are more complex, there is little to gain from it in time to market terms. It is faster to continue doing things the same way than changing old habits. You will need for people to assume there's need for a change and likewise naturally accept that nothing like what is promised in SO will come for free.

3) It is not cheaper:

You will have new roles with SO advent and this can mean hiring. There is a lot of new technology to deal with and this means training. The organization implementing SO will change dramatically and naturally this implies more cost than before. 

4) Is is not revolutionary:

There is nothing new in SO, besides the fact of joining, standardizing and demanding together some of the best practices from previous technologies. This means you are not supposed to forget what you've learned about the best way to build a class or a component. There are specific aspects to consider when doing a service but underlying it we'll need well built components, as before.

5) Is is not a product:

No matter what corporate sellers will tell you, ignore them. You can't buy SO. There is a lot more about SO that what will come in that package they will try to sell you. You don't buy business agility, you have to get more agile processes. This requires people to have a common vision and cooperate to fulfill it. SO is all about cooperation and transparency. Will this come in a software box?

6) Is is not about just doing services:

Many times I hear people saying they are now service oriented because they have built some services. SO is more about best practices than is about services. Sure, you will have services in SO but you also can have hundreds of services and never reach a service oriented state for your business processes. In fact, SO is much more a road you should follow than a place you can go. I prefer to say: "we are on a way to SO". This makes much more sense to me.

8) Is is not self-managed:

Introducing SO, you have lots of new reasons to monitor the systems pro-actively. You need to know a lot about your services: when they fail and why, what is affected and get notified in multiple ways. Even if you are building a super-cool architecture with a lot of P2P agents and smart stuff, service governance will not be done automatically: you will need specific services, applications and the people who operate them.

9) Is not a developers problem:

You may be a bit worried if you hear someone saying that SO is a developer's problem, not our department. But you can get really worried if you hear your CEO saying so. That will mean something is wrong with your SO initiative. Check point 6).

10) Finally, will not vanish if we just sit and wait:

Depending on how much you are allowing your company to loose, you can ignore SO. There have been several trends like this and you are still open to public, I know, but how long will you sustain not having the business agility demanded by customers and showed by competitors? Will you keep your big ball of anything?

After exploring SO misconceptions, in Part II, I will focus on some facts. Until there, please accept my invitation to comment on your own SO experience.

Thanks to Microsoft, Fullsix and Logical Software, who organized and sponsored the first Scrum Master Certification training ever delivered in Portugal, I am now a Certified Scrum Master. As recognized by Mitch Lacey, our Certified Scrum Trainer, the attendees were a very dynamic and focused group that made the training experience very pleasant. For those of you who didn't had the chance of being there, I decided to compile and share some of my personal notes I wrote during the training. I usually only take note of things that really got my attention or that I want to check in more detail later. I'm doing this sort of a disclaimer because I know none of them will be a revelation to people who ...

According to this report, "AMD’s March 2003 introduction of its Opteron processor, followed by Intel’s March 2004 release of a family of x86 64-bit processors under the Xeon brand name, changed the landscape considerably [My note: the landscape of having to use an Itanium processor and either run slower emulated code or revise and recompile to 64-bit]. These processors almost completely closed the divide between 32-bit and 64-bit architectures because systems based on the x86-64 processors can support 32-bit Windows operating systems and 64-bit Windows operating systems. Even better, both 32-bit and 64-bit Windows on x86-64 processors are fully capable of hosting the majority of existing 32-bit Windows applications without performance degradation or recompile".

This support is possible on Windows through WoW64, meaning that you may have the need to support Windows 32-bit on Windows 64-bit, or in other words, to distribute 32-bit applications for 64-bit Windows platforms. In that case, this document describing WoW64 Best Practices may be useful.

That said, although generally speaking we have potential benefits from larger memory support, faster computation and data transfers, we will not always gain performance from this migration. I suggest that if you have doubts on this, evaluate it on a per-case basis: test it before and test it again afterwards. 

So, if you are (like I am) considering to migrate your server installations to 64-bit architecture, you may come across some issues. An example: it is not possible to install TFS 2005 or 2008 on a 64 bit single-server installation: "Team Foundation Server requires that the application tier run in a native 32-bit environment". It is documented in the Installation Guide, for 2005 and here, for 2008. This of course means that in order to use a 64-bit database installation to support TFS, we will need at least another server.

Meanwhile, if you are not sure about what you should do for your development process in order to be ready when and if the migration happens, there's a simple configuration you can use when compiling your C# code: "AnyCPU". This setting will make your application run as a 32-bit application on a 32-bit platform and a 64-bit application on a 64-bit platform, without recompilation (check WoW64 Best Practices and this chat transcript with the 64-bit CLR Team for more details on this).

Being a good architect is not an easy task to do. This January, I was in Norway for the Architect's Master Class with Juval Lowy, from IDesign, and one aspect that I've found interesting in what concerns this course organization is the way Juval assigned time to the 3 main areas we discussed: Process (1 day), Technical (2 days) and Design (2 days). Why I've found it interesting? Well, because it looked a real perspective to me, thinking in the way I'm used to spend my working time nowadays: a portion of project management, a bigger portion with technical lead and also some more time discussing/doing design and prototypes.

In my view and strictly speaking, project management should not be in the architect's roles but in practice, the hybrid-transitional state of our profession requires so. Many times, we don't have the possibility to rely on good-enough (or even existent at all!) project management, so we'll have to do it ourselves in order to ensure the project will accomplish its goals.

Another question that is around for some time now is about if an architect should/must be a good coder. While I can think of a good enterprise architect who knows very well how to lead strategically an organization but he can't be a programmer, if we are thinking of a solutions architect, this competence is not optional. A professional solutions architect generally does not do daily development for a living, but it will be impossible to sustain required technical competence and leadership without good programming skills, staying at the edge and doing prototypes to prove design will work.

And what about design skills? An architect is always researching in some area, looking for future trends and needs of the business he is working for or, generally speaking, "designing for the future". As quoted in a recent Intel presentation about the new 45nm processors technology, the following sentence from Frank Lloyd Wright says it all: "An architect must be a prophet... If he can't see at least ten years ahead, don't call him an architect".

Overall, the course delivers good value and it gives Juval's expertise insight to WCF internals, which is in fact one of this course's assumptions, that is, you'll be using WCF to design your architectures. At the end, I thought the hats I'm used to switch daily made more sense together than before and I felt good. By the way, in IDesign's site there is a video you can watch about all this. Go for it!