software engineers = taxi drivers and vagrants?

I was in a Service Oriented Architecture class last week and the instructor told us that as he got out of a taxi the taxi driver looked up at the building and said "oh yeah, I remember that building. I programmed a lot of Fortran in that building". My instructor said that he was surprised to hear this coming from this guy. Yesterday, a coworker sent me a picture that he had said someone had taken. See below... Yes, one thing that is true of the IT profession is that one cannot let up on their laurels tooooo long -- or one risks becoming truly obsolete. IT changes soooo fast. Case in point, last week I was coming through the airport on a business trip. I had not one but two personal computers with me as I went through the security check. One being my "work" computer; the other being my truly "personal" computer. I laughed as I remembered my Dad and thought that he wouldn't believe it if he were alive (he died in 1987) that I routinely walked around with two computers that I carried in a little bag thrown over my shoulder. When he died, one of the loves of his life (besides my mom and me) was his rather large Sperry desktop computer. Believe me, one could not walk around the airport with this thing. ;-D

t-shirt about job moving to India and all they got was a lousy shirt

Apparently there are a lot of t-shirts being sold that says "My job just moved to India and all I got was this lousy shirt". (see next post about book with similar title) Apparently, Yamini Narayanan, an Indian-born 35-year-old with a Ph.D. in economics from the University of Oklahoma was interviewed by a newspaper reporter. After graduation, she had worked for a U.S. computer company in Virginia and had recently moved back to Bangalore with her husband to be closer to family. When she was asked how she felt about the outsourcing of jobs from her adopted country, America, to her native country, India, she responded with a revealing story: "I just read about a guy in America who lost his job to India and he made a T-shirt that said, `I lost my job to India and all I got was this [lousy] T-shirt.' And he made all kinds of money." Only in America, she said, shaking her head, would someone figure out how to profit from his own unemployment. And that, she insisted, was the reason America need not fear outsourcing to India: America is so much more innovative a place than any other country.

excerpt from "My Job Just Went to India (And All I Got Was This Lousy Book)"

Here is an excerpt from this excellent book:

I awoke to an odd smell. Where am I? I asked (aloud, I think). I was in Bangalore, India’s Garden City. That odd smell was the remarkably foreign combination of pollution, ultraspicy food from the hotel’s kitchen, and something else that I could never quite put my finger on. It was my first morning there, and I was late for work. I didn’t feel bad about that, considering the hellish 32-hour journey I had suffered to get there. And that my India-savvy co-worker tricked me into an all-night cultural immersion in the world’s scariest hotel, after getting off the plane in Bombay the night before. After coming to, I felt a panic, realizing that my driver must have been waiting downstairs for an hour. Oh God, he’ll be angry, I thought, as I scrambled to get ready for the first in a series of all-day interviewing sessions. That’s just what I need on my first morning in a place like this...an angry taxi driver. I rushed downstairs, resisting the fabulous aroma of a South Indian breakfast, and ran out to ask the doorman to page my driver. I asked if the driver had been there long. He had. Two hours. Ugh. I spent the first five minutes in the car with Joseph apologizing profusely over being late and making him wait. He laughed dismissively. This is my job. I wait all day. And as I found out later, he really did. He didn’t just drop me off at work and come back at a fixed time. He waited at the office until the very minute I was ready to go. Without warning, at any time, I could come down from the office and expect to hop into the car and be driven away.


My first exposure to India in daylight was that drive across town from the northwestern corner of Bangalore to the southwestern corner. The culture shock started to hit me. Bangalore is known as India’s Silicon Valley. Being from a small city back home, it was exciting to realize that I had come to a technical mecca. More surprising, though, were the extreme contrasts between high tech and low tech. I saw half-naked children playing in the dirt in front of a huge Yahoo! sign. I saw a rickshaw with a Novell advertisement on the back and another with what looked like a Sun Solaris CD dangling from the rearview mirror as an ornament. We drove past beautiful, state-of-the-art office buildings, filled with the employees of some of theWesternworld’smost innovative companies. We dodged buffalo in the street and begrudingly yielded to rickety bicycles and full families on single mopeds. We passed by fields containing huts made from twigs, mud, tarps, and assorted garbage. We drove through crowds of well-dressed young people, drinking coffee outside their office buildings before the start of the day, only to drive a little farther to be propositioned by lepers begging at a traffic light. So before I even reached the office on my first day, my perspective had changed. This was a world of great extremes. These foreign voices I had heard through scratchy, unreliable phone connections, attached to the brains whose code I’d been ruthlessly reviewing, lived here? These are the people who are allegedly stealing our jobs? I had come to India in the first stage of the setting up of a new software development center for my company. My job was to interview and select about 25 people who would form the "seed team" of a development shop that would eventually house 250 people. More precisely, my job was to rejectmore than 200 people. We had advertised our open jobs and received nearly 30,000 applications. That’s four zeroes. You are reading it correctly. We hired outside firms to help us whittle the 30,000 down to a more manageable number and then used our own U.S.-based employees to further work that number down to a short list of a couple hundred that we could interview in person. I was to be our interview panel’s executioner, sniffing out the weak and finishing them off quickly and (I hoped) painlessly. While in India, I visited the hotel conference rooms of three different cities and met hundreds of people. I probably took a secret pleasure from the fact that I was going to go over and stop all these people from getting through the system and "stealing" our jobs. It was post-boom time. By that, I mean the DotCom bubble had burst. The IT sector’s lifestyle had gone from rock ’n’ roll to Holiday Inn lounge act, and it was showing in India as well. In fact, what I found was not an army of people, plotting to steal our comforts for themselves. Unlike their counterparts in the West, these people weren’t angry that they had to get a small television set or even that they might not be able to afford this month’s cable TV bill. These were sons and daughters who were scraping by, trying to raise money to support their parents and their spouses’ parents. These were mothers and fathers whose IT jobs meant the difference between really educating their children or sending them to a school from which the further educational options have a hard limit. They weren’t trying to steal the American dream. They were trying to squeeze a once-dry economy for a few drops of life-giving cash flow. Ultimately, I was an executioner very much fit for the task. No physical injuries resulted, but many interviewees left with bruised egos. What I left with was a changed perspective. Things had changed. A vibrant society of highly motivated and intelligent people existed here. And they weren’t playing for amenities; they were competing for the survival of their families. You can’t underestimate—or blame—someone with that kind of motivation.


Things Ain’t What They Used to Be


According to the U.S. government, IT unemployment has doubled since 2000. The Bureau of Labor Statistics reports that between 2000 and 2004, the number of programmers in the American IT industry dropped by 17%. In just the first three months of 2005, U.S. techology companies cut 60,000 jobs—twice the number cut in the same period of the previous year. The numbers are sobering. In this world in which every device seems to contain a computer, could software development be a doomed profession? Matters are made more confusing by the bipolar temperament of the IT job market. Had you left and went on retreat in a cave in 2000 for several months, you would have emerged into an IT employment landscape that was as unrecognizable as Java to a COBOL programmer. In the mid- to late-nineties, a gold rush took place in the IT industry. I remember reading about employers giving BMWs as signing bonuses. A team from another company actually auctioned itself off on eBay for a huge signing bonus. IT employment was a seller’s market, and people were jumping ship from other vocations in droves. The market was suddenly being flooded with new talent (or, at least, people who considered themselves talented). At the time, demand was still outpacing supply. I saw Java programmers being shipped in from India who seemed to have passed the time during their flights reading their first Java manual. The flood surely gave passage to some great software people. But it also introduced a large population of peoplewhowouldn’t have ever considered a career in software—and probably shouldn’t have. We’re all painfully aware that the boom has ended. When the bubble burst, it was as if an unruly bunch of children had been interrupted jumping on the bed and suddenly realized how much of a mess they had made of their room. It was a mess they now had to clean up. Our industry was filled with piles of unneeded software, hollow business models, and increasingly irrelevant people. The turn of the century sawIT being demoted fromknight to squire. Organizationally, CIOs had bubbled to the top, often reporting to their companies’ CEOs. They were now being reorg’d back down under the COOs and CFOs where they started. And with this demotion came the budget cuts. Where IT departments were previously under pressure to scoop up the best talent before the competition did, they were now under pressure to shed the excess baggage they had collected. In many cases, the reduction in force didn’t come with a reduction in workload. Bubble or not, the technology boom made our businesses more reliant on IT than ever before. Business processes from the sales floor to the call center were now resting on the backs of IT’s systems. So, here we were with way too much work to do and way too few jobs to support all the work. What’s a poor CIO to do? "Offshoring." This silly-sounding made-upword now strikes fear into the hearts of IT professionals throughout the Western world. Too much work mixed with budget reductions leaves little choice for the nation’s CIOs. Programmers in India can be hired for as low as a tenth of the salary of a programmer in the United States. And without a standardized, objective way to compare and contrast the talent difference, that’s a bargain difficult for a smart business person to turn down. Even with the time zone and cultural differences, it’s hard for a finance manager to imagine not saving real money with the right offshoring setup. So, jobs have been shipped overseas by the boatload. Many American programmers have found themselves either unemployed or supporting the skeleton crew as one of the last of a dying breed. Early-morning or late-night teleconferences through fuzzy telephone connections with people who "talk funny" are becoming a common occurrence in the software development world. And it looks like the burst of the bubble didn’t make a temporary trough. This is the new IT landscape. Over the years since the boom, offshoring has been growing at a steady rate.


In 2004, IT outsourcing grew by 37%. And according to Gartner, a research and advisory firm, worldwide offshore spending on application development will more than double, reaching $50 billion dollars by 2010. It’s not just grunt work that’s going, either. While we’re already spending $1.2 billion on R&D outsourcing, that number is expected to shoot up to $12 billion by 2010.3 The IT offshoring boom has been historically associated with India. India started with a marked advantage over many other low-cost countries, largely because of its excellent educational institutions and, more important, the prominence of English as a first or second language. But even for India, competition is heating up. More and more business is being shipped to Eastern Europe (where it’s easier to find multilingual employees to support European language–speaking nations), Russia, Malaysia, and the Phillipines, to name just a few. Most recently, China has begun to figure into the equation. You know, China. They’re the ones who manufactured almost everything in your house. Go to Wal-Mart, and try to buy a clock or a phone that wasn’t made in China. It’s a real challenge. And now, they’ve got some forward thinking Indians wondering how long the "offshoring bubble" has left in India. Leading management consultancy McKinsey & Company reports that although it will be some time before China could eclipse India in IT offshoring, progress is being made. Chinese offshoring revenues are increasing by 42% each year on average, and the number of English speaking college graduates in the Chinese workforce has more than doubled since 2000. The bottom line is that things have changed for us professional software developers here in theWestern world. All signs indicate that the change is not temporary. We can expect our DotCom bubble glory days to become a more and more distant memory as the world continues to turn to lower cost sources of software development labor.


It’s All Our Fault


It’s easy to demonize Big Money America or criticize the government for not protecting us. Or, for the truly adventurous of imagination, it’s easy to believe that Indians have developed some sinister plot to maliciously rob us of our comforts. However, even if there is an ounce of truth in these sentiments, it is outweighed by the pounds ofmediocrity underwhich our Western industry has languished for the last several years. It’s understandable that forlorn programmers would dump their personal tragedies at the feet of anonymous companies and governing bodies. It’s somehow comforting to drown one’s fear or despair in a healthy helping of anger and strategically directed blame. And to make matters worse, media sensationalists such as Lou Dobbs prey on our fears, hyping up the problem and sounding a rallying cry whose primary purpose is to get better ratings. But ultimately, blaming corporations is a dead-end road. We can’t change corporate America. And though we have democracy on our side, none of us can single-handedly steer this massive ship of a country. So though comforting in times of fear and uncertainty, this game of blame the big-guy is fruitless. We have no one to blame but ourselves. This self-blaming attitude isn’t defeatist, though. In fact, blaming the government is the defeatist choice here. Forming labor unions and picketing would be defeatist. Sitting on the couch flipping news channels and cursing in a fit of nationalist ragewould be defeatist. All these courses of action lay the blame—and the imperative for action—at someone else’s feet. If we can calm down enough to look at the situation rationally, we see that it is our own fault that we’re in this mess. We live and work in an economic ecosystem. In ecosystems, it’s the strong who survive. During a period of staggering success, we’ve allowed ourselves to get fat, lazy, and slow. The state of our craft has been marred by years of mediocrity. The fact that we can take responsibility for and see the path that led to our predicament is a good thing. It means we can start to take (and own) corrective action. It’s Up to Us It’s time to face the music. We are where we are, and waiting for things to change by themselves isn’t going to lead us anywhere different. The trends aren’t reversing, and the government has no incentive to bail us out. The good news is that each of us has the power to do something about it individually. We can each take control of our own piece of the situation, bringing sanity to the collective whole. Of course, if you can’t stand the heat, the most obvious action is to get out of the proverbial kitchen. Western IT has its share of post-boom deadweight still lingering around, nervously drawing a paycheck. For some not-insignificant percentage of IT workers, the safest bet is to start looking for an alternate line of work. Choosing when you leave and where you go next is a lot less difficult than being thrown out. If you don’t have passion and a drive that would force you to create softwarewhether you were being paid for it or not, you’re not going to be able to continue to compete with those who do. For those who remain, here is the key to survival: Software is a business. We’re going to have to be business people. Our companies don’t employ us because they love us. They never have, and they never will. That’s not the job of a business. Businesses don’t exist so we can have a place to go every day. The purpose of a business is to make money. To stay employed, you’re going to have to understand how you fit into the business’s plan to make money. As we’ll explore later, keeping you employed costs your company a significant amount of money. Your company is investing in you. Your challenge is to become an obviously good investment. If the business value you bring is clear, you are far less likely to end up on the offshoring chopping block. Think of your career as if it is the life cycle of a product that you are creating. That product is made up of you and your skills. In this book, we’ll look at four facets that a business must focus on when designing, manufacturing, and selling a product. And we’ll see how these four facets can be applied to our careers:


1. Choose your market. Pick the technologies and business domains you focus on consciously and deliberately. How do you balance risk and reward? How do supply and demand factor into the decision?
2. Invest in your product. Your knowledge and skills are the cornerstone of your product. Properly investing in them is a critical part of making yourself marketable. Simply knowing how to program in Visual Basic isn’t good enough anymore. What other skills might you need in the new economy? How can you compete with both your offshore and onshore rivals?
3. Execute. Simply having employees with a strong set of skills doesn’t pay off for a company. The employees have to deliver. How do you keep up the delivery pace without driving yourself into the dirt? How do you know you’re delivering the right value for the company?
4. Market! The best product in history won’t get purchased if nobody knows it exists. How do you get find recognition in both your company and the industry as a whole without "sucking up"?
...


Ultimately, the goal is not to bring our jobs back. These low-value jobs we’ve lost were meant to be sent offshore. Instead, we should be preparing for the new wave of higher value jobs that will be created in their places.

web 2.0 & web 3.0

I spent a little time this weekend looking at aspects of web 2.0 and 3.0 and how these can be relevant to the business world. Of course in NG we are using such ideas as wiki. Its amazing how helpful the wikipedia site has become to me. Anyway, sites such as myspace are interesting if nothing else than just to note that this site is now the 6th most popularly accessed site in the entire WORLD. We really do all need to be at least cognizant of the ways the younger generation (such as my son) is using the web in the context of social engineering. How might we use these ideas ourselves? Perhaps not to find a date….but perhaps to make an important IT or business connection? (or even to find a date for myself…LOL) Okay…so young folks are using the web in drastically revolutionary ways and it seems that us *older* folks are always behind. Anyway, I have picked up some books on things such as ajax and am looking forward to getting caught up a little with some of the newer technologies. Of course ajax is already mainstream. I read a book this week that provides some *excellent* ideas on thought leadership. You might not know it looking at the book cover and title, which is "My Job Went to India and all I got was this Lousy Book". The book cover shows a rather forlorn looking guy on the street holding a sign saying "Will Code for Food". I picked up the book because I found the cover amusing. But inside I found gems of wisdom. Probably the most important book I have read in ten years. Now I just need to go about putting into action some of the author's suggestions. :-) Anyway, its interesting to type in some words on the Google Trends page. You can type in a word such as J2EE and see that top most requested searches for that word are almost all coming from India. But if you look at the Google Trends for something such as Ruby for Rails you see that those searches mostly come from Silicon Valley and the area around MIT. This is just one small way to kind of monitor what the top IT gurus are up to. The idea is that J2EE is already well commoditized and is being off-shored. If someone starts today to learn J2EE they are already *far* behind the curve. I think an important area to watch is the Semantic Web. I think this is one area that is going to absolutely explode. How might the SOA, BPM, and the Semantic Web converge? What might become possible with the convergence of these 3 ideas? How might we use that convergence to help our customers? Anyway, just things to think about…

By the way, if anyone is ever bored (which I know we never are…), you might go to http://99-bottles-of-beer.net and peruse through the syntax of a simple algorithm in some 1,069 languages. This is just an amusing thing to do…. A little more exciting than programming "Hello World"...

cartoon relevant to BPM

Jess

Jess is a rule engine for the Java platform, and is a superset of CLIPS programming language, developed by Ernest Friedman-Hill of Sandia National Labs. In at least one (possibly two) of my expert systems classes I actually wrote some programs in the CLIPS language. Jess provides rule-based programming suitable for automating an expert system, and is often referred to as an expert system shell. In recent years, intelligent agent systems have also been developed, which provide a similar capability. Rather than a procedural paradigm, where a single program has a loop that is activated only one time, the declarative paradigm used by Jess continuously applied a collection of rules to a collection of facts by a process called pattern matching. Rules can modify the collection of facts, or they can execute any Java code. Jess can be used to build Java applets as well as full applications that use knowledge in the form of declarative rules to draw conclusions, and inferences.

Options for Legacy SOA-Enablement

Legacy integration aims to revitalize and extend the reach and lifetime of legacy systems by exposing existing functionality through the use of wrapping. It adds a front-end software layer to hide unwanted complexity and exposes modern interfaces to ease interoperability. The options for integrating legacy systems are:

User-interface wrapping or screen scraping, where legacy screens are mapped into modern graphical or Web service interfaces. Advances in the capabilities of Web-based, screen-scraping products make development of these interfaces easier with nominal development effort. However, this option makes sense only for applications that are user-interface intensive.

Data wrapping, where new interfaces are developed for the legacy data structures to allow direct access using standard SQL or XML technologies.

Business-logic wrapping, where legacy functionalities are wrapped and programmatically accessed through custom object-oriented wrappers, EAI adapters, or Web Services interfaces.

Legacy wrapping requires less up-front architecture and design, and it can reduce integration costs and provide a roadmap to incrementally reengineer and transfer legacy components to a new platform without having to go through a "big bang" type of replacement of the system. However, legacy wrapping can only provide a tactical, short-term solution because it addresses the integration and flexibility pain points without impacting the source code significantly. True flexibility will be achieved only by understanding the legacy source code repository and refactoring it to some extent.

service wrapping of legacy systems

Research efforts and commercial providers have proposed various approaches to address the pain points of legacy systems. However, the major problem remains: the identification of useful legacy functionality that can be exposed for collaborating applications at an optimal level of granularity. Additionally it is important to estimate and analyze the consequences of service-enablement decisions on the system-quality attributes (such as performance and maintainability) and the solution cost. In this regard, a systematic and comprehensive method to guide the transformation and integration of legacy applications with an enterprise-level architecture such as service-oriented architecture (SOA) is currently lacking. SOA using Web Services is gaining acceptance as the primary mechanism to interconnect disparate applications and ease interoperability between heterogeneous systems for internal as well as external integration. It promises improved business agility and reduced integration costs through increased interoperability and reuse of shared business services. One of the key obstacles to realizing this vision is the service enablement of existing legacy applications to collaborate in an enterprise-wide SOA. Over the past few years, significant advancements have been made to modernize and improve the interoperability of legacy systems.

What is the semantic web?

Wikipedia states: “Humans are capable of using the Web to carry out tasks such as finding the Swedish word for "car", to reserve a library book, or to search for the cheapest DVD and buy it. However, a computer cannot accomplish the same tasks without human direction because web pages are designed to be read by people, not machines. The semantic web is a vision of web pages that are understandable by computers, so that they can search websites and perform actions in a standardized way. A computer could, for example, automatically find the nearest manicurist or book an appointment that fits a person's schedule.”

I predict a really cool convergence between SOA, BPM, and the semantic web sometime in the future.

what is architecture?

What is Architecture?
ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems, provides the following definition for architecture:
Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. This definition is intended to encompass a variety of uses of the term architecture by recognizing their underlying common elements. Principal among these is the need to understand and control those elements of system design that capture the system’s utility, cost, and risk. In some cases, these elements are the physical components of the system and their relationships. In other cases, these elements are not physical, but instead, logical components. In still other cases, these elements are enduring principles or patterns that create enduring organizational structures. The definition is intended to encompass these distinct, but related uses, while encouraging more rigorous definition of what constitutes the fundamental organization of a system within particular domains.

Here is my definition for Architecture:

Architecture is the set of decisions that must be made at the enterprise level before specific applications are designed and built in order to provide conceptual integrity and sanity across the enterprise’s systems. Architecture includes a decomposition of the systems into separate orthogonal viewpoints along with the enforced rules that enable this clean decomposition and isolation of design viewpoints. This is done so functional (application requirements) and non-functional (system qualities) and other aspects of the application system may be defined and built by independent specialists in their specific field. An architecture not only divides the system, it also divides the roles and responsibilities of those who work with the system into separate organizational concerns and disciplines that are conceptually tractable and can be effectively managed.

what are some desired traits for a system/software architect?

This is what I desire to grow into one day: ;-D

Architect’s Personality and Other Traits

No empirical studies have been done to determine the best character traits that define a successful architect. But it’s reasonable to derive the following traits based on the duties of an architect.

An architect is a human filter that process complexities and outputs an abstract high level model of a system. Conveying the output to the stakeholders requires excellent communication skills – written, verbal, and presentational.

An architect is a negotiator. The method of principled negotiation should be the tactic of choice for an architect. This method is most suitable in contrast to soft or hard negotiation method, because it seeks mutual cooperation between an architect and project stakeholders. An architect will be expected to deliver better, faster, and cheaper, but since only two-way combo can be selected an architect must negotiate to decide which aspects of a system will be considered first
and under what conditions.

An architect must convey a sense of credibility and trust; an architect must be perceived as successful. An architect can attain such status with his prior successful experience, formal training in the field (certifications in the future), and by his or her ability to deliver successful and relevant architectural artifacts through every stage of the SDLC.

An architect believes in his ability to perform well. In a leadership position attitude is everything – if the passion for success is absent, then an architect must step down from the leadership pedestal.

An architect must be patient and resilient, as the only thing constant is the change itself. Since software architecture has direct influence on the quality characteristics of a system, an architect will interact with a great number of people with a full spectrum of personalities. He or she must quickly adapt to the way stakeholders operate, as it’s not possible or feasible to expect them to speak the language of an architect.

In order to be effective, an architect must be familiar with the business domain at hand so that solutions crafted are practical and less academic. At the same time an architect must stay in touch with the rapid evolution of the field as the discipline grows towards becoming a true engineering discipline. New methodologies, practices, and vendor tools are re-defining, again and again, the responsibilities and duties of an architect. Proactive participation and involvement in the software architecture community in is a duty of every architect.

What is a software architect?

This was a definition I found somewhere.... I was trying to figure out what it meant when people called me an architect. ;-D (I guess I am a wannabe architect)

A software architect is responsible for creating or selecting the most appropriate architecture for a system (or systems), such that it suits the business needs, satisfies user requirements, and achieves the desired results under given constraints. This article describes the myriad responsibilities of a software architect, and attempts to identify human personality traits that naturally aid a person in such position.

An architect abstracts the complexity of a system into a manageable model that describes the essence of a system by exposing important details and significant constraints.

An architect maintains control over the architecture lifecycle parallel to the project’s software development lifecycle. Although an architect may be most visible during the requirements and design stages of a project lifecycle, he or she must proactively monitor the adherence of the implementation to the chosen architecture during all iterations. Architecture on paper is fruitless unless implemented proficiently.

An architect stays on course in line with the long term vision when projects’ scope creep attempts to manipulate software architecture in a certain way in order to satisfy the desires of myriad stakeholders. An architect must focus on actions that produce results early while staying on course for the long term. When project variables outside of one’s control change the architect must adjust the strategy given the resource available while maintaining the long term goal.

An architect progressively makes critical decisions that define a specific direction for a system in terms of implementation, operations, and maintenance. The critical decisions must be faithfully made and backed up by understanding and evaluation of alternative options. These decisions usually result in tradeoffs that principally define characteristics of a system. Additionally these decisions must be well documented in a manner understood by others.

An architect sets quantifiable objectives that encapsulate quality attributes of a system. The fitness of the architecture is measured against set marks.

An architect works closely with executives to explain the benefits and justify the investment in software architectures. This may be done by participating in business process re-engineering activities, by using Cost Benefit Analysis Method, or by measuring the level of component / architecture re-use between projects with the help from the software process improvement team. Software architect must be effective in order to deliver results that are meaningful to the projects that have an impact on the bottom line that result in greater profits.

An architect inspires, mentors, and encourages colleagues to apply intelligently customized industry’s best practices. Educating the recipients and participants of system architecture is essential to successfully selling the chosen architectural path. Specifically the stakeholders must be able to understand, evaluate, and reason about software architecture. If an architect is the only one who can read and understand documented system architecture, then he has failed to integrate his best practices into the organizational culture.

An architect fights entropy that threatens architect’s structural approach to problem solving. It’s an architect’s job to keep the inertia going once the project is in progress. He or she must convince all relevant stakeholders that the chosen approach is sound – moreover the chosen architectural solution must be well explained and justified. The benefits of implementing a system in a particular way must be explained not only in terms of “that’s the right pattern for this problem,” but also to demonstrate the measurable benefits - such as easier integration. For example, in a product line approach an architect must be able to demonstrate how the subsequent projects will be easier to implement due to the presence of a common base from which subsequent work can be done.

An architect creates and distributes tailored views of software architectures to appropriate stakeholders at appropriate intervals. For example, a customer may demand to become more involved with a project and they may need to know an abstract view of a system on the level understood by them. A government customer may require an architect to demonstrate early in the project how a given system meets High Level Architecture requirements for a specific framework. It’s the architect’s responsibility to identify and present a sufficient level of information that a customer needs.

An architect acts as an agent of change in organizations where process maturity is not sufficient for creating and maintaining architecture centric development. If the concept of software architecture is not well recognized in an organization it may be a “tough” sell to formally recognize the role of software architecture in a SDLC. Without senior management commitment and without mature software development process, architecture of the system on paper may not reflect the actual architecture of a system.

what are some job duties of a system/software architect?

I had to fill out some goals for an employee evaluation. I asked my HR director what my job description was according to my "job code". He told me that he really couldn't tell me what my job was -- that it was between me and my boss. (LOL) So I googled the definition of architect to see what I could find out about potential responsibilities for the title. This is just part of what I found: (it made me feel a little tired reading it--kind of like wow, that's a lot of work! (LOL))

· Provide leadership in setting technical architecture and design direction.

· Lead one or more technical business application areas and projects of high complexity or criticality.

· Control critical cross-functional projects, related project risk, technical execution and resulting impact on business and strategic plans.

· Partner with Project Managers to define and deliver global and strategic technical projects.

· Provide application system development and technical support, implement complex technical strategies, and recognize/resolve issues and opportunities of a highly complex, critical nature.

· Initiate analysis for complex problems and issues, determine technical alternatives, analyze vendor solutions and negotiate contracts, and collaborative develop appropriate standards for technology applications.

· Define project technical objectives and ensure project deliverables are aligned to support goals.

· Provide analysis and solutions to technical and business issues.

· Understand and apply technology and corporate vision and direction in implementations.

· Maintain awareness of business and technology strategies and implement technical alternatives and strategies to gain competitive advantage.

· Manage vendor and partner relationships, and maintain the complex technical infrastructure of assigned area to meet business requirements.

· Provide technical leadership and consultation to project team members in execution.

· Initiate and conduct feasibility studies of new and modified operational procedures.

· Ensure solutions/designs are cost-effective.

· Provide direct guidance in planning, designing, programming, documentation and implementation of the systems.

· Perform reviews of new and existing systems to ensure operational integrity and accomplishment of stated objectives.

· Design, code, test, debug and document programs as required.

· Provide consultation and assistance to corporate and business organizations in the preparation of project plans as assigned.

· Assist in the development of the strategic technical architecture plans in partnership with the business or staff department.

· Provide technical solutions to business problems, technical leadership and direction to management.

· Assist in the management of the partnership with the business unit.

· Remain current on technical and professional advances and business strategies regarding area of responsibility.

· Serve as expert in area of responsibility, identifies process improvements and problem prevention, and provide advice to management as appropriate.

· Ensure compliance monitoring is in place, including processes for management of operational risk, in accordance with regulatory standards.

Gartner BPM Summit
February 26-28, San Diego California

On February 26-28, 2007, I attended the BPM Summit in San Diego, California, along with approximately 1100 other attendees. I attended the conference as a guest of Singularity. In addition, I spent altogether about a full day at the BPM Technology Showcase. I made a short appearance at the BPM Summit’s Hospitality Suites. I spent a short amount of time with e.POWER chief technologist Steve Kruba. And I found that one of the most impressive speakers was Sonya Sepahban from Northrop Grumman. According to Gartner, Sepahban is the Sector Vice President of Mission Excellence and a Chief Engineer for the Northrop Grumman Space Technology organization. I loosely following track D of the conference, titled “Managing the BPM Technology Environment”. Following is the list of sessions I attended. Below this list I provide some of my observances and impressions of the conference.

Monday:
Welcome and Introduction
Keynote: Business Processes: The Foundation Linking Business and IT (Simon Hayward, Gartner)
Process Modeling for Profit (Marc Kerremans and Robert Jirgal, Gartner)
BPMS: A Change from Business as Usual (Janelle Hill, Gartner)
Lunch Address (Pegasystems)
BPM in the Real World: Linking BPM and SOA Delivers Long-Term Flexibility (IBM)
The Power of BPM and SOA for Human and System-Based Process Optimization (Metastorm)
Mission Excellence in a Process Management Culture (Sonya Sepahban, Northrop Grumman Space Technology)

Tuesday:
Keynote: The BPM and SOA Elixer (Daryl Plummer, Gartner)
Keynote: What BPM Means to Business Innovation (Bruce Williams, CEO of Savvi International Corporation)
Build for Change Winning Through Business Agility (Pegasystems)
Best Practices and Methods (Appian)
Lunch Address (Appian)
The Service Repository Enables BPM (Daryl Plummer, Gartner)
Collaborative BPM: A New Way to Think (Toby Bell, Gartner)
The Bigger Picture—Embedding BPM into Enterprise SOA (SAP)
Building the Business Case for Business Process Management (BEA)
Securing BPM (Neil MacDonald, Gartner)

Wednesday:
Business Applications Through 2010: Major Changes Will Affect Your Process Environment (Yvonne Genovese, Gartner)
People Ready Processes on the Microsoft Platform (Microsoft)

My favorite speakers were Daryl Plummer, Bruce Williams, Sonya Sepahban, Neil MacDonald, and Janelle Hill.

Daryl Plummer is hilarious. For instance, at one point in his talk he had us chanting “POLY-MORPH-ISM”. He wanted us to do that, he said, just because it was such a cool word. He said that even if one doesn’t understand the meaning of the word, they sound smart just by including it in their vocabulary. Plummer told us straight-up that we were all wasting our lives if we did not use TiVo. And I don’t really remember what he said but he gave some kind of analogy of COBOL programmers liking beer while Visual Basic programmers liking wine and Assembly programmers liking whiskey. I don’t really remember exactly what he said but it was funny at the time. He also said that it was a very sad day in America when we were all terrified of Y2K and treated COBOL programmers like they were Gods. At one point he said that he had been a geek throughout his life but that he was also cool because he was a musician. Then someone from the audience yelled out that it didn’t matter – he was still a geek.

On a somewhat more serious note, he gave an analogy that I am sure Dr. Bob Ellinger would appreciate. He said that people are service oriented and event driven. Every morning we hop into a shower and use a water "service" to clean ourselves. If the phone rings, or the neighbor's cat somehow gets cornered by our Rottweiler, we hop out to handle the "event." If we answer the phone-ring event, we are using a phone "service"; and, he figured that our neighbor (the cat lover) would consider it a "service" if we saved Fluffy from becoming Rottweiler kibble. So, he exclaimed that people are service oriented and event driven and that our systems should be service oriented and event driven too.

On an even more serious note, he said that Business Process Management and Service-Oriented Architecture each have significant contributions to business agility, cost reduction, and speed to market -- but combined, their power multiplies. He said that BPM will be one the largest consumers of services, and will take on aspects of service creation through linking to standard Service Oriented Development of Applications (SODA) environments:

The subtitles in his talk were:
The Business Case for BPM & SOA
Why is There SOA in My BPM and BPM in My SOA?
“Don’t Come to the SOA/BPM Picnic without the SODA”

He summarized the results of Gartner's 2006 CIO survey (he said that "CIOs are programmers that manage to pass for normal folk"), where it was found that the top business trend and concern is improvement of business processes. He said that there is a lot of pressure to automate processes and improve them and that this is going to happen only with SOA and BPM complimenting one another. He said that processes need services to be implemented quickly and effectively, and services aren't of much use unless they are consumed by processes. He said that SOA allows us to build an infrastructure of shared services for ready consumption by processes.

He said that one of the key reasons for SOA and shared services is that legacy applications are still hanging around, in spite of all our efforts to get rid of them. Adding a service layer over the legacy applications allows us to create higher-level services and processes that consume these services without having to know how -- or even knowing what platform they use -- to access the data directly on its original platform.

Plummer said that SOA is an architectural style: not web services (although web services can be used to implement SOA), and is not a particular product but is encapsulated functionality accessed through a standardized interface that allows for loose coupling of services and applications. (He also had us chant “EN-CAP-SU-LA-TION”.)

He continued with a discussion of event-driven processes (he refers to them as event-driven services in counterpoint to BPM-driven services). He said that services, properly implemented, can be combined into event-driven processes rather than structured, pre-defined processes in order to be able to respond to events that happen in an unexpected order or manner. His view of the "new" application container is user interface and navigation via portal, security and management as part of the network, and logic and data via collection of services. Explicit orchestration ties all this together, which provides agility in the process model.

He then pointed out that SOA is never finished: in fact, it's designed to never be finished. He used the analogy of the Sagrada Familia in Barcelona, Spain, a cathedral that's been under construction for more than 100 years, and continues to change even as it is built. He covered some things about development techniques to be used when developing services within an SOA infrastructure, and highlighted the business service repository as a centerpiece for BPM's use of SOA.

He introduced the Agility Quotient, which is "...calculated by measuring the things that inhibit agility and examining how willing one is to overcome them", which someone said striked them as being a new age-y business measurement that did more to increase Gartner's consulting revenues than any customers' agility.

Another point he made was that agility and speed were not synonymous. He said that you can very quickly create another legacy environment (he said in fact you probably already had).

Bruce Williams of Savvi International is the author of Six Sigma for Dummies (and the accompanying workbook) and Lean for Dummies. Williams pointed out one view of BPM: that of a faster, better treadmill, but everyone was still doing the same old things. He said that BPM is more than that. He said that it was not just operational efficiencies and defect reductions, but measurements and activity monitoring, process controls, and integration between systems and services. Furthermore, he said that the biggest value from BPM was in business innovation, not process improvement. He asked us why innovation was important. The answer was pretty obvious, although ignored by many traditional organizations: the lifecycle of every product or service eventually comes to an end, often because someone else introduces a disruptive product or service to the marketplace that obsolesces the old way of doing things. He said that ultimately, innovation always trumps optimization.

Williams continued with a lot of stuff about why the innovation cycle looks like it does. He talked about classic reasons for why products or services pass their peak: fatigue, customer demands, market redirections, competitive pressures, technological changes, globalization effects, organizational changes, demographic shifts, regulatory constraints, economic effects, supply drifts and many other factors. He pointed out, however, that most US firms have no program in place for fostering innovation, and don't even have a clear idea of how to become more innovative. He said that most companies are focused on product innovation, and mostly ignoring things like business model innovation, business process innovation, and things such as innovation in accounting practices and risk management.

He went through some of the different dimensions of innovation -- reactive versus proactive; incremental/sustaining versus radical/disruptive; formal versus informal -- and looked at how these dimensions mapped onto some specific cases. When he referred to Americans as the kings of innovation, however, it made some doubt his world view overall and I am sure left many with a bit of a bad taste: it came across somewhat as ethnocentric flag-waving that probably has no place at a business conference. While Americans lead innovation in a number of areas, there are many other countries in the world that are leaders in their own areas of innovation. He said that most people in the world lived in cities and that they all wanted the same things as those of us at the conference. He showed a slide of things such as SUVs, dogs, large houses, etc. and tried to give the impression that everyone in the world wanted what many Americans seem to treasure: an SUV full of consumer goods and a monster-sized home in the suburbs. He pointed out with some pride that he had completed a survey which concluded with the prediction that if everyone in the world lived like he did, we would need over 7 planets worth of resources to accommodate them.

At the end of it all, he had very little to say about BPM, but a lot to say about innovation and suggested that was one of the prime motivators for why one might be considering BPM.

Alan Trefler, the CEO of Pegasystems spoke. He was engaging with amusing graphics but one phrase that really grabbed me was "you have to get away from the poisonous import/export environment so that BPM doesn't become the next CASE". He said that the one word that will kill organizational agility is “export”. What he meant by both of these statements is that by modelling in one tool, then exporting it to an execution environment where there is imperfect round-tripping, there's a danger of having the processes caught in the execution environment where one is stuck maintaining it in a more code-like environment: presumably, the execution environment has imperfect modelling, or you wouldn't be using another modelling tool in the first place. This makes the modelling tool useless except for the initial design process, and therefore hinders the future agility of the process. He says that CASE (think back to the 80's and 90's) introduced nice-looking tools which generated code that could then be "tweaked", but one then ended up doing further code maintenance in the code environment rather than the CASE environment because there wasn't proper round-tripping between the environments. He said that in the world of BPM, this is not what we want.

At both Gartner BPM Summits that I have attended, there has been a lot of talk on Six Sigma. I, for one, don’t have a clue what Six Sigma really is. I guess I need to pick up that “Six Sigma for Dummies” book. In fact, that was the focus of Sepahban’s discussion.

Jim Sinur introduced the idea of a BPM Maturity Model. The following paragraphs describe the five levels of this model. I also brought back a poster summarizing these levels. Perhaps I will hang it in my new work area since the walls are so badly banged up and in dire need of a paint job.

Level 0: Acknowledge operational inefficiencies, with potential for the use of some business intelligence technology to measure and monitor business activities. Maybe be need a -1 level wherein the organization is in complete denial about their operational inefficiencies. In CMM (the Capability Maturity Model for software development processes), for example, level 0 is equivalent to having no maturity around the processes; level 1 is the "initial" stage where an organization realizes that they're really in a lot of trouble and need to do something about it.
Level 1: Process aware, using business process analysis techniques and tools to model and analyze business processes. Think Visio with some human intelligence behind it, or a more robust tool such as those from Proforma, iGrafx or IDS Scheer.
Level 2: Process control, the domain of BPMS, where process models and rules can now be executed, and some optimization can be done on the processes. They admitted that this is the level on which the conference focuses, since few organizations have moved very far beyond this point.
Level 3: Enterprise process management, where BPM moves beyond departmental systems and becomes part of the corporate infrastructure, which typically also opens up the potential for processes that include trading partners and customers. It is important to have BPM (and BRE and BI) as infrastructure components, not just embedded within departmental applications, because it is nearly impossible to realize any sort of SOA vision without having these basic building blocks.
Level 4: Enterprise performance management, which starts to look at the bigger picture of corporate performance management and how processes tie into it.
Level 5: Competitive differentiation, where the business is sufficiently agile due to control over the processes that new products and services can be easily created and deployed. Personally, I believe that competitive differentiation is a measure of how well that you're doing right from level 1 on up, rather than a separate level itself: it's an indicator, not a goal per se.

We started the last day at the Gartner summit with a keynote by Yvonne Genovese, Business Applications Through 2010: Major Changes Will Affect Your Process Environment. Early in her presentation, she made an important statement: "the technology keeps breaking our processes". Her focus is on business applications, not specifically BPM, but she's looking at trends of what's happening with enterprise applications like ERP and CRM systems. Her point is that these business applications have, in the past, forced businesses to use rigid business processes implemented within those systems. However, the current trend is towards unbundling some of this functionality, exposing it through services, and then consuming those services using a BPMS. This allows one to not only call specific functionality from their business applications at any point in a process that one now controls, but actually replacing or augmenting the functionality of those applications by calling other services. This also provides an opportunity to more easily integrate between business applications if one has multiple ones in their environment. Although the business application vendors have been pushing suites for some time now, that packaging model will be less compelling to their customers as organizations start to slice and dice the atomic functionality of the business applications and compose their own processes using BPM rather than use the suite in its monolithic form.

Business applications aren't going away: there's still a huge amount of good functionality available in them, and as long as that commoditized functionality can be consumed as services, one isn’t going to be writing a replacement themselves. What I think will happen, however, is that the amount of the functionality used from any given business application platform will begin to erode as other internal or external services replace some of that functionality. This frees organizations from the vendor lock-in that they're subjected to now, and adds a new possibility for creating business applications: instead of just "buy" or "build", you can now also "compose". And if the megavendors in this field are going to stay competitive, they need to embrace and encourage an ecosystem that allows smaller vendors to provide services that can easily be integrated with their larger platform. This isn't going to be the old model of the vendor controlling the ecosystem by annointing their favorite technology partners, however: the customer organizations are going to build their own ecosystem from their preferred vendors in a truly best-of-breed fashion.

At the end of the day, BPM is an essential part of all this, since it will be used as a composition framework for combining functionality from business applications, along with internal and external services, into the processes that the business really needs.

Microsoft is honing in on business process management with the formation of the Microsoft Business Process Alliance and the release of a BPM roadmap that will include a key standard—Business Process Execution Language—in the Windows Workflow Foundation. The company announced that it has formed this alliance and it consists of about 10 companies dedicated to building out BPM functionality on Microsoft's platform.
These companies include IDS Scheer (a key process modeling partner with SAP and Oracle), Fair Isaac, Global 360, Metastorm, Ascentn, SourceCode Technology Holding, AmberPoint, InRule, PNMsoft and RuleBurst. The goal of the alliance is to break down barriers to BPM deployment—particularly for small and midsize businesses—by providing a less expensive BPM technology deployment option for companies, Microsoft officials said. Microsoft also announced that it will provide further support of the Business Process Execution Language (BPEL) standard in a pending update of a key business orchestration tool. Furthermore, Microsoft plans to provide further integration between WWF and its BizTalk Server product as part of the BizTalk Server 2006 R2 release, which the company said will be generally available in the third quarter of 2007.

Another observance of the conference is that within the next few years, Gartner predicts that businesses will demand an entirely new mix of expertise within their IT organizations -- but technical skills aren't likely to top the list. Gartner says that by 2010, the demand for IT infrastructure and services expertise will shrink by 30% or more. Meanwhile, demand for business process and relationship management skills will double.
By 2010, 40% of staff members within IT organizations will have substantial business and non-IT experience. This prediction was foreshadowed by the makeup of attendees at the conference, 40% of who were from business units rather than IT organizations. One of the speakers said that IT organizations will become increasingly automated and outsourced. As a result, IT employees will be asked to fill multiple roles, rather than just focus on a single job. And one of their most important roles will be managing "points of interface" with other parts of the business. IT employees will need to speak the same language as business stakeholders. This means less demand for specialists (IT employees with a deep understanding of specific technology) and more demand for generalists (IT employees who have a broad set of relatively shallow technology skills). IT will still need technical skills, but the most valuable technical employees will know how they can apply those skills to different situations in different parts of the business. IT organizations will need to cultivate versatile employees, what Gartner has coined as "versatilists." These versatile employees will have broad experience in business and will be well-known and recognized as being credible high performers by other people outside that specific business domain.

EMC Corporation announced the availability of the EMC Documentum Process Suite, a comprehensive BPM solution for analyzing, modeling, orchestrating and optimizing a wide range of enterprise processes involving people, systems, content and data. EMC claims that the Documentum Process Suite is the only offering on the market that delivers a complete BPM suite leveraging EMC's comprehensive portfolio of information infrastructure offerings to provide organizations with the ability to manage both processes and the information that drives them. This introduction of the Documentum Process Suite marks the integration of the process analysis and business activity monitoring software gained from EMC's June 2006 acquisition of Proactivity Inc., with EMC's existing Documentum business process management capabilities.

Simon Hayward said that the 1980s were about quality and process improvement; the 1990s were about Business Process Reengineering; and the 200s are about BPM. I have other presentations that I have previously put together that highlight the similarities and differences between BPM and BPR.

Hayward said that the problem (or limitation) with those approaches were that it was assumed that if one could only correctly capture the requirements that the IT project would be successful. Still today the Systems Engineering disciplines put a lot of emphasis on the Requirements phase of any project. The problem with this is that there was a basic assumption that the requirements wouldn’t change. And of course it was also assumed that one could know and articulate their requirements. BPM is about agility and focuses on the metrics and ability to adapt in a dynamic and rapidly changing environment.

Hayward mentioned some common entry points for the introduction of BPM: corporate performance management, packaged application upgrades, application integration, deployment of applications supporting collaborative and informal work processes, and fulfillment of compliance measures.

Hayward stated that Gartner predicts that by 2010 process modeling will be adopted on a scale half as big as spreadsheets. Gartner also predicts that by 2010 the artificial separation of OLTP and decision support will be obsolete, replaced by case management as the preferred design pattern. And by 2012, technologies to support BPM will have been absorbed into other products and will no longer be a distinct category.

Other things I noted were:

SAP advertised their Business Process Expert Community via their website. They said that there is information and resources that will be of interest to all persons interested in BPM, whether or not they are an SAP customer.
In addition to BPM, other uses for modeling include: project validation, administration reorganization, costing, Quality Management, application development, reference architecture, enterprise architecture, risk management, and implementation of business applications.
Some best practices for modeling are: leveling, top-down approach, gradual progress, simple tools, and focus on documenting what really happens in an organization as opposed to focusing on what’s documented. Other best practices are: modeling work in parallel, embracing a culture of constant reevaluation and validation, and use of reference architectures.
From the security session, I picked up that SPI Dynamics and Watchforce have about 80% of the web application security vulnerability scanner and source code scanner market.
Three top reasons for BPM are productivity, visibility, and innovation.
IBM has bought FileNet and Webify.
The number one BPM modeling tool used today is PowerPoint.
IBM has a SOA Readiness Assessment on their website
Receive, route, report = procedural automation; research, respond, resolve = declarative automation
Other best practices are: hire a cyberlibrarian; identify, buy, or build searchable registry; reward engineers for reuse; and provide a reuse feedback loop

Books to read are:
Reengineering the Corporation
Medici Effect
Creative Destruction
Power of Process
The Faces of Innovation
Extreme Competition

Sites to review are:
ibm.com/soa/soabusinesscatalog
ibm.com/software/innovate
myfootprint.org
innocentive.com
bijonline.com
bpm.com
bpmg.org
bpmi.org
bpminstitute.org
bpm-today.com
bptrends.com

Things to think about are:
genchi genbutsu