06.04.08
Posted in Application Development, Application Lifecycle Management (ALM), SOA & Web Services at 12:45 pm by Tony Baer
Of course that’s a loaded question, because anytime you modularize or componentize software, reuse is supposed to be one of the goals. Posts this week from Joe McKendrick and James McGovern once again spotlighted the issue, with Joe commenting on McGovern’s blog, explicitly entitled “Reuse is not an SOA Concept.”
McGovern makes the case that reuse occurs more meaningfully at high level; he suggests focusing on business rules because that’s more meaningful to business stakeholders than services, which are programmatic instantiations brought the issue back to the forefront. McGovern states quite bluntly, “In terms of enabling reuse, maybe enterprise architects need to stop believing the crap about BPM and instead figure out that the more practical level of reuse occurs by reusing business rules,” adding that analysts tend to ignore this approach because the business rules industry is so tiny.
We need to separate these arguments to make sense. We’d concur that reuse at the service level is somewhat meaningless for several reasons. First, what constitutes reuse? Does that mean you must reuse the same instance or replicate of a service, just part of a service, or a service design pattern?
That brings us back to some comments from IBM’s Steve Mills and Grady Booch yesterday at the Rational user conference, where Mills spoke of the success to which IBM Software group has employed reuse to speed time to market. Rather than reinventing databases and application servers, IBM Software has reused DB2 and WebSphere application server hundreds of times in its products. In his talk on the beauty of software, Booch on the other hand, spoke of measuring success of a software project by the prevalence of design patterns throughout the code. Each have valid points, but let’s place them in context. Mills is running a product organization where what comes out of software development goes straight to the bottom line, and where the assets (in this case entire applications) are quite explicit. Booch speaks of reconciling the diversity of software development with the goal of not reinventing the wheel.
From our standpoint reuse works best either at high levels (e.g., reuse a chunk of DB2 or WebSphere) or at very low systems-level service levels (e.g., why write new error functions?).
But when it comes to services, we’d concur that’s not what the business is going to demand; rules or processes are easier to comprehend. As to whether that involves 100% exact reuse of a specific service is an IT decision. And back to McGovern’s arguments over rules vs. business processes, that’s a matter of semantics. He reasons that rely on rules or policies. The prevailing view is that business rules are intrinsic to these larger functions and that you need to resort to specialized business rules engines when your rules are so complex that they merit separate attention. He also claims that there is such a small, specialized business rules management segment is that many kinds of systems, from business process management to IT service management, that most analysts dismiss or ignore it. We don’t think that it’s a zero sum game of business rules or business processes; different sectors will have different needs. We part paths with McGovern there.
We’ve commented here and here that reuse should not be the criterion of success in measuring the success of SOA. Instead, as we discussed when we shared the stage at an Open Group EA forum last winter with McKendrick, David Linthicum and others was that the best measure of success from SOA comes from whether it helps your organization increase its business agility.
Permalink
Posted in .NET, Application Development, Application Lifecycle Management (ALM), Java at 2:55 am by Tony Baer
Returning to the stage of the Rational Software Development conference after a 3-year absence, Rational amigo emeritus Grady Booch spoke of the undiscovered art of software engineering. At the keynote, Booch spoke of the renewed importance of systems engineering (more than a neat coincidence, given the recent Telelogic acquisition) because, frankly, big old systems are going to keep on going (as we learned the hard way during Y2K), and that new big web systems are, well, going to keep on getting lot bigger (just throw out stats about Google, Amazon, eBay, and any video streaming site).
The result is that there’s going to be a need for a lot of specialized knowledge that doesn’t normally exist, or exist in great numbers, among enterprise software teams. The previous day, we asked Booch about how to bake in the specialized knowledge that apps living large are going to need. That provided entrée for the more predominant theme of the conference, which was the focus on collaboration, and not so coincidentally, Rational’s new Jazz framework and emerging family of offerings.
(Actually, it sparked a momentary debate between Booch and the other of The Three Amigos still standing, Ivar Jacobsen, who maintained that aspect-oriented programming provided an approach to satisfying cross-cutting requirements; Booch replied that AOP was too low level to handle the issue. But we digress…)
On one level, you could say that Jazz is ClearCase on steroids, in that it is built around a new source code control system and repository that, in contrast to ClearCase, is based on a relational database rather than a file system. But the secret sauce is the workflow that surrounds so-called baselines with all the tasks, processes and alerts, and eventually, enterprise reporting that pertains to it. And it uses a RESTful architecture to make information pertaining to a software project available from any place on the web that exposes the data as a simple service. In other words an integration bus, that adds workflow, tasks, and alerts to the fabled old source code control system. And if you get the APIs accepted widely enough, a hook for other tools to associate their domain-specific tasks as part of the overall workflow.
Guess what, Microsoft Visual Studio Team System (VSTS) has provided something similar, minus the source code repository, but adding a data warehouse which, thanks to the Cognos acquisition, IBM will add to Rational Jazz probably in the 2009 wave of releases. But this is not about who’s first. As VSTS is for the .NET world, the development world needed a similar idea for the rest of us. For Rational, it breaks the bottleneck of its original software delivery lifecycle vision, where it bought a whole bunch of tools but never integrated them.
More importantly, it’s about waking up a market that has been so damn comatose since the combined whammy of the commoditization of IDEs and the popping of the dot com bubble. ALM is not simply a portfolio of tools that vendors piece together through acquisition that are unified under a common brand, and maybe a common look and feel. The software development organization is actually a bunch of tribes that have traditionally operated inside their own silos, and until now, ALM vendors have sold tools that have reinforced those silos. Clever point integrations between, say, a source code control and defect tracking system, simply papered over the boundaries separating the programmer from the QA tribe.
ALM vendors can no longer hide behind their poverty – e.g., that no single vendor can afford to put the framework together that spans the different constituencies from business analysts to requirements specialists, architects, developers, and testers because, well, you couldn’t charge SAP level prices for an IDE or testing system.
Instead, it’s about the realization that, if you’re going to call yourself an ALM vendor, and if ALM is to become a real market as opposed to a collection of silo’ed tools sold a la carte, there needs to be more than lip service to integration. It’s also about the realization that there won’t be any great repository in the sky, a lesson that TI, Microsoft, Rochade and others learned the hard way back in the 90s. Developers are too damn independent, which actually is a good thing – regimentation, and regimented tooling, are not the formula for good software development. At the end of the day, it’s about the idea of federation that in effect, applies a form of BPM on the tribes of software development, and the multiplicity of tools that comprise the development environment.
Permalink
Posted in Application Development, Application Lifecycle Management (ALM) at 2:44 am by Tony Baer
According to ex-Rational Rational guy Grady Booch, the best software is software that you don’t notice because it just works. Arguably, he’s not talking about the presentation layer, which, for software like the Mac OS, actually is something that you see and is what distinguishes it. But we’ll leave that argument aside for the broader point that Booch was making: software is not a physical artifact, pointing to an attempt of his several years ago to get some landmark software exhibited at the computer History Museum in Silicon Valley. In the end, what was displayed was the box for Photoshop.
Well, Booch admitted there was an exception even to that argument: on early space probes, software had to be kept small and simple because too much processing translated to too much thermal load, which can be an issue for spacecraft. So there was something physical about it.
Back to the main point, Booch is concerned that software is such an intangible in that the knowledge behind the code is often not codified, and therefore, remains within the brains of developers who, alas, are mere mortals and eventually retire – as we learned the hard way during Y2K.
To try to redress that gap, Booch delivered a keynote at the Rational Software Development conference on the “beauty” of software, displaying the architectural patterns of about eight or nine famous software programs. Examples included the Canadian air traffic control system, which introduced the concept of a moving object that moves its package of data from one node to the next; or the subsumption layered architecture of the Mars Pathfinder, which purposely omitted provision of a central processor; and the Google architecture, optimized for reading rather than writing data, with the goal of providing results that may not be exact, but are good enough.
His point is that there is artistry in well-conceived software architecture just as there would be in a complex physical system in the real world, like a suspension bridge or cathedral. He would have loved to have gotten a hold of the source code for the original MacPaint, a 10,000-line program that contained only what was necessary and no extra frills or extraneous logical loops – but Apple being Apple, wouldn’t release the code.
For Booch, the point isn’t simply worship of aesthetics, but the transfer of knowledge for a field where the process is all too fragile. He worries about a possible “digital dark age,” which is his way of saying that bits are fragile, and so are the architectural practices that go with them. If a software program gets so larded with patches over time that it become a jumble, or of more concern, that the bits become unreadable because the format is no longer supported, will we (1) be able to retain a record of our history and (2) learn anything from past architectural innovation? He gave the example of JPEGs; a century from now, will any device be able to decipher them?
That’s not such an idle worry as we learned firsthand during the transition to DOS 5, which changed the backup file compression format, rendering all of our early Wordstar floppies worthless pieces of plastic. In that sense, we lost our own history – a personal loss that as data formats grow obsolete, will be multiplied billions of times over.
Permalink
06.03.08
Posted in Application Development, Enterprise Applications, SOA & Web Services at 12:01 am by Tony Baer
AmberPoint’s latest release of its SOA management tooling acknowledges that, when you’re tracking service level performance, it’s typically about more than just the service. We’ve railed a number of times that there’s a gap between managing service level agreements that may have some performance and availability requirements that may ultimately be governed more by infrastructure. For instance, when demand for a specific service peaks, and segmenting service customers into different tiers is not enough to get SLAs in compliance with your premium customers, it’s probably time to provision some additional infrastructure capacity. But SOA management, or run time governance tools, are owned by the software, not the IT operations group. It’s an area where we’d like to see movement, especially from IBM and HP, which have software businesses aimed at both constituencies.
But AmberPoint has broadened the target, while still sticking within the confines of the software group, in that its latest release adds end-to-end transaction monitoring. That is, it’s adapting its technology to extend back to source applications. Well, for now AmberPoint’s moves are only a first step, in that their initial rollout is only supporting a set of transaction apps used by their telco customers: Amdocs, for order management; Clarify, for customer relationship management; and NetCracker, for demand management. SAP is an obvious next target given that AmberPoint is at least partially funded by SAP Ventures.
The reality is that service level management respects no boundaries. What AmberPoint is doing is breaching just one of those boundaries. At an analyst meeting at the Rational Software development conference earlier this afternoon, we heard Rational head Danny Sabbah speak of some of the other boundaries: the line between software quality on the software development side, quality of service once software enters production. And while Rational has begun lining some of its ducks up with Tivoli, the reality is that IBM Software (nor anybody else for that matter) has figured how to sell quality solutions that bridge development, deployment, and operations – because the interaction between operations folks and developers often trends more toward finger pointing.
Permalink
06.02.08
Posted in Rich Internet Apps., Standards Development, Web 2.0 Apps at 10:36 pm by Tony Baer
Nexaweb this week is trying a new tack for taming Ajax development. Problem is, JavaScript lacks the strong typing, and so until now, the best solution has been for all the tools players to have their own custom frameworks for generating JavaScript libraries used in Ajax. The alternative has been to develop in JavaScript, something that is barely a side specialty for most web app developers. Nexaweb’s idea is to propose extensions to the Dojo toolkit that impose an XML-based abstraction layer so you can reduce the need to shell out into raw JavaScript coding, much the way the Spring framework eliminates the need to write all those J2EE artifacts while taking advantage of J2EE services. It’s an interesting shot in the dark from a player that is decently sized fish in the small fishbowl that is the Rich Internet Application (RIA) tooling market.
In so doing, Nexaweb is tilting at windmills because the Ajax style, and the culture that has emerged around it, has tended to be very fast and loose – and resistant to standards. That accounts for the rash of enterprise mashup hubs and protected sandboxes, as they are based on the idea that, while you may not be able to clean up Ajax-style development, if you place firmly guarded borders around it (e.g., carefully vet what can be mashed up), at least you won’t smother it.
Permalink
Posted in .NET, Application Development, Application Lifecycle Management (ALM), Java, Open Source, SOA & Web Services at 12:10 am by Tony Baer
We admit that it’s been sounding like a broken record, but for the past couple years, we’ve wondering when Rational would finally emerge from its roughly decade-old slumber. After having pioneered the concept of application lifecycle management before the term was actually coined, the company stood on its laurels with a suite of largely standalone tooling silos glued together by tape and baling wire.
This year, Rational is finally fleshing out what others have already dubbed ALM 2.0. After unveiling Jazz, its SOA-based ALM integration backplane a year ago, it’s finally releasing the first new products to natively leverage the technology. Rational is ushering in the Jazz Age with the obvious candidate, Team Concert, which has been in beta over the better part of the year, which in effect forms the gateway to jazz. Then it adds a couple pieces that are “nice to haves” but are hardly essential.
To recap, Team Concert is the collaboration portal that encompasses source code control, work item, and build management. Then there’s Requirements Composer, a kind of an in-between tool, somewhat akin to Borland’s Caliber DefineIT as a white boarding medium, that neither replaces partner offerings like iRise, which prototypes the look, feel, and flow of applications; or RequisitePro, where you formally enter detailed requirements for the record. Finally there’s Quality Manager, providing a quality dashboard sitting above test management that’s intended to add business-level traceability to quality issues that traditionally were tracked as more cryptically as software defects.
Admittedly, Rational is not first to the ALM 2.0 game, but like others that have already taken steps (e.g., Microsoft, Serena, Compuware, MKS), it’s just the beginning of a journey. The challenge to integrating the application lifecycle has always been that the constituencies are so diverse, with each requiring different blends of assets at different rhythms. For instance, while each process, from requirements to modeling, coding, and testing should be iterative, the length and speed of iterations will vary based. Unless you are heavily into agile methodology, chances are, requirements development iterations are likely to be longer running processes compared to, say, coding and testing. And, while the artifacts of coding and testing are largely machine readable, requirements are meant for humans to decipher.
Suffice it to say that as rev 1 offerings, IBM’s not telling anybody to pull out their ReqPro or ClearCase installations. In fact, given the huge landed investments that Rational customers have in their legacy tools, it’s always going to remain a matter of federation and coexistence. Besides, when you look at the sociology of software development orgs, you are always going to have bastions of trendy and legacy practices. That’s exactly the use case that IBM painted regarding its own internal beta implementations. For now, ClearCase, ClearQuest, and ReqPro will have interfaces to Jazz; later on the roadmap, IBM is promising native integration. (Other roadmap items cover enterprise reporting, project management, tie-in of rational Method Composer, not to mention a future enterprise edition of Team Concert.)
After flirtation with Eclipse-based individual productivity tools, we’re glad that IBM’s finally tackling the heart and soul of the Rational product line. It’s taken awhile, but it required a changing of the guard (after the golden handcuffs came off Mike Devlin, a team from the WebSphere group took over) to pull off.
For Jazz, the most obvious contrast is to Microsoft Team Foundation Server, targeted at performing a similar role with .NET development. But less noticed is the Eclipse Application Lifecycle Framework (ALF) project lead by Compuware and Serena. From a marketing standpoint, it’s obvious as to why IBM wouldn’t want to share spotlight with those whose penetrations it already dwarfs. But no matter how public or “open” the development of Jazz, the burden of proof remains on IBM to demonstrate why the world needs yet one more vendor-specific ALM framework, no matter how “open” it already is.
Permalink
« Previous Page « Previous Page Next entries »