A VP in charge of an IT organization recently remarked, "We're really not developing software anymore in the traditional sense. All of our new requirements are being satisfied by either a packaged application or an integration of existing components. When we have to do custom software development, we usually outsource it to lower our production and delivery costs."
This comment reflects a new reality for IT executives and a new paradigm shift for IT shops. Today's IT professionals need to be of two minds: One requires a technical understanding of new and old technologies; the other requires understanding the business value of technology, and how to position an organization for competitive advantage.
Today's IT executives are increasingly concerned with integrating packaged applications into their legacy environments -- much more than they are with building software programs from scratch. The emergence of SOA is a good example of how "reusable components" are having an impact on the changing roles, responsibilities, and challenges facing IT professionals. Not only are IT pros expected to be "nuts and bolts" technologists, but they're also expected to be managers who are capable of governing the interplay of a total software system, which includes legacy code, off-the-shelf packages, and some code written in-house. In this regard, IT professionals today are called upon to do less software design and construction and do more management of the total software system delivered to their end users.
On the business front, IT executives are frequently in the hot seat when it comes to justifying their budgets. Gone are the days of open reqs and the carte blanche attitude, If you build it, we will buy it. Rather, software developers are taken to task with hard-hitting questions: "How will this software application help our company solve our business needs?" "How do we know that you're designing and constructing the right kind of application in the first place? " What is the application's return on our investment?"
This article introduces a new IBM Rational strategy for Architecture Management that helps IT leaders and architects answer these questions and prepare their organizations to support changing business requirements on any scale.
Architecture management responds to a new IT reality
The IBM Rational team is currently expanding what has been traditionally called Analysis, Design, and Construction to include Architecture Management: the discipline of governing software architecture amidst changes to the requirements that drive it and the code that implements it. This discipline has to ensure architectural integrity alongside a company's unique and evolving business processes and models. Architecture management reflects a fundamental shift in the emphasis of software architecture in that it's the business driving the design; not the design driving the business.
What's driving the need for architecture management?
Architecture management has been shaped by three forces currently changing the nature software development: SOA, geographically distributed development (GDD), and the business practice of outsourcing and offshoring. Let's take a look at each of these driving forces to see why architecture management is becoming critical to the design, adoption, and deployment of new software applications.
Much has been written about how service-oriented architecture, or SOA, will help companies maximize the efficient use of people, processes, and technology. Ideally, each company's approach to SOA embodies the means by which its IT organization remains agile, competitive, and highly efficient -- all in an effort to maintain a customer-centric focus. Based on the reuse of existing applications, or portions of applications exposed for reuse via a service model, a functioning SOA relieves software developers from designing and constructing applications from scratch. Decisions previously made regarding database schemas, operating systems, server platforms, and programming languages remain intact and viable for future recombinations. Engineers no longer work at the rudimentary level of files and code modules. Rather, they work at a higher level of abstraction to address the business value of the software they are proposing. For this reason, applications -- transformed via SOA into services -- are structured so they can be stored, easily discovered, and recombined to create a new business application quickly.
To fulfill the SOA vision, however, is a tall order. You clearly must have those services in place in order to reuse them. You can't reuse something that doesn't yet exist. More to the point, you can't just build "services" willy-nilly. They have to be built according to a prescribed set of standards, protocols, and interfaces, which after all is what makes them "standard" and "reusable." This is where architecture management serves a vital purpose: You've got to architect your services so they can be reused in a service-oriented architecture fashion.
The reality of geographically distributed development (GDD)
It's become more of the norm than the exception for software development organizations to have their development staffs spread out over geographically dispersed sites. Many times GDD happens through mergers and acquisitions: Companies don't instantly relocate and co-locate people or shut down one operation and/or merge them. With telecommuting and the availability of remote technologies, companies find that it's more cost-effective and practical to keep its staff in place at different sites.
The IBM Rational organization offers a good example: It has Development Centers (IBM calls them Labs) in far-flung geographic locations, and its software developers may all be working on the same product and same release. This new style of workforce configuration begs the question: "How do you do 'architecture' when your developers are spread out all over the place?" More important, "How do you maintain the integrity of the architecture?" If someone asks, "Show me your architecture," your answer needs to be in line with the implementation that's associated with it. From a business view, the architecture needs to be in line with the latest business requirements driving the architecture in the first place. This need to keep requirements, design, and implementation in sync has always been a challenge, and is only exasperated in the context of GDD.
The business of outsourcing and offshoring
Many companies are engaging in some version of outsourcing and offshoring. These are special forms of GDD where development is distributed not across the sponsoring organization but to outside parties often located far distances away. One extreme (and a less common scenario) is a customer that outsources all its IT needs -- for example, the company is based in Ontario, and it has a firm in Bangalore, India that's providing the company's entire IT capability. Headquarters may be doing some business modeling, but the contractors in India are doing all the architecture, all the design, all the coding, and all the testing.
The more common scenario that IBM Rational anticipates is a customer who keeps the requirements and architecture (design & construction) in-house, but outsources the "core" implementation work. This kind of customer wants or needs to stay close to their business requirements and how they transform into design, but is motivated by lower labor costs available for doing broad implementation work. In this scenario, the architecture will be implemented with some degree of "truth" or correctness, but in practice, it won't be perfect. The implementation, by choice or by accident, will inevitably deviate from the design, resulting in some degree of architectural degradation. Architectural degradation can happen in any scenario, GDD or otherwise (e.g., you can be co-located and your implementation team can be next door or down the hall and you can still experience it). As stated earlier, GDD makes it harder, and outsourcing even harder because it's a different company, a different time zone, and different communication and/or language barriers. In this example, after an outsourced company writes the code, it comes back to the customer to be assessed. The fundamental question that is posed is: "Did the contractors implement the architecture the way it was written?" Chances are, to some degree, the answer is "no."
Herein lies the challenge: Architecture Management must help software architects assess the "as-built architecture" against the original design, and ultimately against the business's needs driving the effort in the first place. To make comparisons, look for differences, and finally reconcile those differences prior to deployment -- this is a core purpose for architecture management.
What are the implications of architecture management?
As the principles of architecture management come to fruition, there will be changes to the way business IT is managed today. Because the discipline of architecture management focuses on business drivers and thus leverages higher levels of abstraction in the technology, we can expect to see a "shift to the left" among those who staff an application development project's lifecycle. That is, the roles involved at each stage of development will themselves remain the same, but the personnel who today fulfill those roles will move left. So, who used to be a programmer will become a designer; who used to be a designer becomes an architect; who used to be an architect becomes an analyst or an enterprise-level architect. In essence, what's happening is the maturation of the discipline called "enterprise architecture." If we can get better at managing software architecture -- which is primarily the definition we're using in the Rational context -- that should result in a shift of some people, time, resources, and staff to what's beyond managing software architecture: that is, to manage everything else that comprises the architecture of an enterprise.
By getting better at managing software architecture, we can then bring in the software with the hardware, data, and operations environment and put it all together under one coordinated tool or system, so that information from disparate and unconnected modeling tools would be integrated to make all that information accessible in a unified fashion. For example, imagine I put out a query: "Tell me all the computers in my company that have architecture module A42 version 6, and tell me what databases are hooked up to it." Today, this is an enormously difficult question to answer. It's strictly a manual procedure, involving a tool that knows databases, a tool that knows software modules, a tool that knows the hardware and deployment; but there is no single tool or even set of tools that can be strung together in a workflow that automates the process such a query requires.
What opportunities stem from architecture management?
Architecture management presents opportunities that can improve the way we design and develop software and in the way we manage change across requirements, design, and code. By shifting the focus further "left" in the lifecycle, we enable our IT staff to be closer to, and spend more time on, the business requirements at hand. And by doing so, we stand to significantly improve the quality and productivity of our overall software delivery process.
But in order to realize these benefits, we need to recognize some of the hurdles found in most organizations today. Essentially, we're faced with two challenges in our attempts to put architecture management into practice. They center on 1) educating and enlightening the IT management and staff, and 2) more robust automation that's needed with the front-end aspects of the software delivery lifecycle.
Even though architecture management is largely an extension of traditional notions of analysis, design, and construction, it's different enough that we should expect resistance from IT shops in general. Software development and delivery has been done for many years, and development organizations have systems in place for getting the job done. Proposals to alter those systems are never taken lightly, and even when proposals are embraced, the change is generally difficult. Like any situation requiring change, education and information is a key element of successful adoption.
The education required for understanding and appreciating architecture management begins begins by accepting that this discipline is not so much new, as it is something that needs to be done better. Designers and developers have always had to manage architecture. But as the driving factors cited earlier have come into play -- SOA, GDD, and outsourcing -- the scalability of doing things the way they've always been done has been compromised. You can only work so many hours in a week, you can only hire so many more people, and you can only train them to create work-arounds for a limited time. Having the development group take a tough, close look at their trends in staff, time, and even employee burnout may be the best education to start with.
Robust automation: Re-tooling the front end
After recognizing the general need for managing architecture better than past practices will allow, a logical choice will present itself: There is a bifurcating trend occurring in the software industry that is taking the market in diametrically opposed directions. One is the use of "cheap labor" (i.e., outsourcing); the other is the use of ultra high degrees of automation through modern tooling. In this regard, developers as we know them today will look very different. They're either going to opt to work in an outsourced capacity, writing code the old-fashioned way because it's going to be cheaper to hire people at pennies on the dollar than it is to buy expensive tools and teach them new methods. Or they're going to shift into doing the upfront, work because that's where they will be needed by the sponsoring organization. And with this natural separation of concerns, the back-end work will either be outsourced, or it will be automated.
We know the dynamics of outsourcing. On the tooling side, one can envision a world in the not-so-distant future where the front-end lifecycle tools are so powerful that they negate the need to outsource core implementation work as we know it today -- even to cheap, low-end labor shops. As the front-end lifecycle tooling gets better, the need to farm out that work to manual implementation teams will become significantly minimized. This means that we'll see two extreme ends, like an hourglass turned on its side: The sand falls on one side or the other, and there is a narrow interface between the two. A bundle of work is going to go into the cheap labor side as it has been doing for several years in IT. For companies who don't have business interests in the outsourced labor market, they'll go to the other side, that is, they will develop tools to automate the business front end, where the architecture takes on its greatest significance.
We began this article by quoting a vice president in charge of an IT organization, who observes dramatic changes taking place in how software is being delivered. These trends are reshaping the need for technology, the way we organize our IT staff, the kinds of tools we need to use, and how we understand our business models and practices. SOA, GDD, and outsourcing are each independent forces with their own role in these trends. Combined, these three forces have motivated us to adapt our discipline of analysis, design, and construction to something that better manages software architecture. The stakes are increasingly high, because we need to better govern our IT methods as we address ever-changing requirements and imperfect implementation work.
There will be some challenges to adopting architecture management as a best practice. But for those organizations facing these trends, it will be worth it, for it will provide a better and more productive way to manage software architecture. In doing so, businesses will be able to concentrate on what they know how do best: their business.
To learn more about the new IBM Rational Architecture Management discipline and the products that help make it a reality, see http://www.ibm.com/software/rational/offerings/design.html
Currently a market offerings manager for the Rational software brand within IBM Software Group, Gary Cernosek is responsible for analyzing and responding to software development market trends, with a focus on requirements management, software architecture, and development technologies. Previously, he held positions in Rational field sales, field technical training, and customer consulting. Prior to joining Rational, he worked as a software developer in the NASA community on space shuttle and space station systems for more than eight years. He holds a B.S. in electrical engineering from the University of Texas at Austin and an M.S. in computer system design from the University of Houston at Clear Lake, where he concentrated on object-oriented software engineering.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
