Shahzad Bhatti Welcome to my ramblings and rants!

Blue collar jobs have been moved to offshore with a little uproar, and offshoring of white collar jobs in IT have received not much fret publically either. Clearly, common folks are losers and multinational companies are winners in this deal. The only slight consolation in all this is that may be third world countries can use this to help boost their living standards and undo brain drain that has been effecting them.

Nevertheless, IT professionals are paying for this and will continually pay. It resulted in not only loss of jobs, but the overall working environment in most organizations has become pretty bad with long hours and a little pay. Many consulting companies are resorting to sweatshop mentality of offshore companies because they think that is the only way they can compete. Smart engineers are betting on innovative technologies that can boost their productivities such as Lisp, Ruby or Smalltalk and using agile methodologies that focus on test-driven incremental delivery and meets customer’s expectations. But that only give you so much headstart because offshore companies will catchup. It’s true that most offshore work is grunt work than innovative, but that will change also. The only advantage companies can have is to hire real good people who are 100x times more productive and that may give them some breathing room. Many studies show that onsite person is at least twice as productive as offshore. However, in most companies decisions are made by suits, who think they cannot miss offshore train and trend will continue in that direction.

Tunnel Visioning Syndrome
In my fifteen years of career, I have come across more than one companies,
that has severe tunnel vision syndrome. Basically, the project starts
modestly with sizable requirements and a few moderately experienced
developers, but as the project grows the only area of focus for the project
remains keep delivering the features. Both business people and developers
are keen on making next release and applying code and fix methodology.
Clearly, the business folks having used to the initial velocity of the
project don’t want to wait and the project size has grown beyond developers’
capabilities.

I consider this a tunnel vision syndrome, when folks are only focusing on
short term deliverables. Though, focused attention is good technique to
deliver one thing instead of juggling too many things. However, you need
peripheral vision to understand surrounding activities and be prepared for
related issues. I like the comparison with gardening where you keep triming
it and maintaining the overal beauty of the garden. But the team is too
busy with features to focus on any kind of minor refactoring or architecture
level refactoring. One thing that contributes is lack of an architect in
the team.

Of course, the heart of the issue lies with using code and fix methodology,
that slows down the fluidity of the deliverables and the team continue
try to meet customer’s expectations. Meanwhile, the code becomes rotten,
the architecture (if there was one) becomes unwiedly. Though, people
start realizing the pain, but they still don’t slow down or try to change
their behavior. The management is clueless and keep harping on deliverables
and developers have buried their heads down in implementing some features.
All this results in big QA cycle that takes weeks to manually test features
and results in hundreds of bugs that come back to developers (code and fix).

The quesiton is how to get out of this if no one is willing to address
the hard core issues or take responsibilites. Obviously one way is to
walk out of this situation, but having been run into these situations
a few times before, I am not sure my next place will be any better.

[Note: these companies have not been small or non-tech related, but
each had more than $100M revenue and 500+ IT staff]

Anemic Domain Model
I read an interesting post from my friend Ed at http://jroller.com/trackback/ewentworth/Weblog/is_the_anemic_domain_model. He responded to MF’s post on anemic domain model. I don’t think this is really about anemic domain model, instead it’s about separation of concerns. You can have objects with behavior that really belongs to those objects. However, some OO bigots stress on “Tell and don’t Ask” based behavior, which means instead of getters tell the object to what to do. This means that I can tell the object to save, print, etc. I think this is taking OO a bit too far. I wonder these people ever maintained a large enterprise system. In real system, separation of concerns or modularization means ease of maintenance and extensibility. I would not want to put persistence, printing or any other external capabilities to my domain objects, instead define them as a service.

As long as using business objects in service interfaces as opposed to DTO, I find that it does lead to simple services. However, in many cases business objects are not simple, instead they have very deep relationships with other objects. So if you need to send these objects in disconnected mode then you have to realize these objects along with dependent objects. This is just additional overhead and cause data-coupling. I like to design services using top down design and based on explicit contract. I want the interface and all objects that it is using or returning explicit. So, I actually prefer DTOs in these cases, because I know exactly what data the service needs and don’t introduce unnecessary data coupling.

SOA/ESB
Enterprises from financial institutions to manufacturers are continuing to adopt technology with the same goals in mind.to make operations more efficient, take advantage of opportunities quickly, and make better decisions than their competitors. But while all of them can purchase the same systems and software, the real advantage comes from being able to apply these tools in innovative and productive ways. Creating an application infrastructure that pays dramatic dividends for the enterprise requires skills in determining how to architect applications that make effective use of core services.

The latest in a line of application infrastructures produced by industry analysts and strategic consultants is the service-oriented architecture(SOA). To many, it sounds like a collection of randomly assembled industry buzzwords. But the concept itself is straightforward. An SOA, at its heart, is a collection of services. A service is a software component that is well-defined, both from the standpoint of software and business function, and doesn’t depend on the context or state of any application that calls it.

These services are typically implemented as Web services, accessible by applications through the Simple Object Access Protocol (SOAP), an XML form transmitted over HTTP. The advantage of using Web standards in an SOA is that the services can more easily adapt to different applications. Nothing in particular has to be done programmatically to the service, except to enable it to receive requests and transfer results using SOAP. So, in many cases, Web services are straightforward for an enterprise to build, and existing software can even be adapted to create new Web services.

How does an SOA give an enterprise a competitive advantage, and enable it to respond rapidly to business opportunities? Simply, it enables an enterprise to define the essential services it requires to serve its core business needs efficiently, and to adapt rapidly to changing business conditions. Once these core services are implemented, any application can call upon them to access and analyze data, build new business models, or provide data or features that make that application immediately pay back its investment.

This means that SOA is both a technical and a business strategy. It’s a business strategy in that services deliver core value to the business. The services that comprise the SOA must be designed with an intimate understanding of the business, in order to determine what capabilities can be used across multiple applications. And they must be general enough to support multiple applications with different purposes, yet specific enough to provide real value to individual applications.

From a technology point of view, the challenge is in the architecture of the enterprise Web services. Because an SOA is fundamentally a flow and a relationship of service interfaces, designing the interfaces and their relationships requires an exceptional knowledge of Web technologies, business processes, and the technology platform underlying the services and the applications that employ them. The architect must understand not only how Web services are constructed, but how they are used by both existing applications and applications planned for the future.

1. Managing for Security
2. Mapping Security to SOA
3. Getting the Big Picture on Security
4. Special Report on SOA
5. Hidden SOA Challenges
6. Designing a Better SOA
7. Explore the Dark Side of SOAs
8. Establish a Service-Oriented Framework
9. Debunking 3 SOA Myths
10. SOA: The End of Integration
11. The Critical Role of Shared Services
12. Avoid Dead-End SOAs
13. Use a Services-Network Approach
14. SOA Report
15. Top 10 ESB Myths
16. Take the Enterprise Service Bus
17. Enterprise Architect Summit 2004 Slide Presentations
18. XML and Web Services: Are We Secure Yet
19. Extensible ESB
20. SOA Design: Meeting in the Middle
21. ESB for Distributed Integration
23. Take the Enterprise Service Bus
24. Chapel Video

What’s Web 2.0
I heard Jason Fried talk about Web 2.0, clearly he is the leader and visionary. Here is a few characteristics I found from his talks and other folks:

• Simple and a few features, i.e. less is more
• Start with interfaces and customer experience (no functional specs)
• Rich Internet Application
• Social networking like FOAF
• Tagging
• YAGNI
• Interactive — AJAX
• SOA
• Decisions are temporary
• Embrace constraints
• Work on immediate features and buy as late as you can
• Examples:
  • http://www.37signals.com/
  • http://www.tadalist.com/
  • http://flickr.com/