Level: Introductory Editorial staff (dwinfo@us.ibm.com), developerWorks, IBM
07 Nov 2006 IBM architecture luminaries get personal. Find out why they do what they do and how they got where they are. Explore the twists and turns of their professional journeys that led them to the world of IT architecture.
Introduction: Rogues or polymaths?
What do you want to be when you grow up? I still think about that, even though I have been working for longer than I care to reveal in a public place. Maybe you do, too. In fact, if you are a baby boomer like me, you will probably ask that question and answer it in any number of ways until you are dragged kicking and screaming into retirement.
This month, we ask our panel of luminaries a version of that question, albeit asking for hindsight instead of foresight:
Why did you decide IT architecture was right for you, and what career path did you follow to become an architect?
As you'll see, IBM technical visionaries are not immune to this kind of soul searching. In fact, it seems that what they share is a constant striving for new experiences, new knowledge. Perhaps this makes them rogues, the word Grady Booch uses to describe himself, which is defined variously as "vagrant" or "mischievous person" by Merriam Webster. (I don't imagine another of the definitions -- "dishonest or worthless person" -- applies in this case.) More likely, this makes them polymaths, people "of encyclopedic learning," according to Merriam Webster. And they all seem to be having a wonderful time!
To the average person who wants to become an IT architect, this might make them all seem a bit intimidating. After all, who gets to be so creative and happy while working in IT <grin>? But each of them started somewhere else a long time ago. Rather than gaining the skills that made them IT architects all at once, they labored long, hard, and in different areas to gain their skills. Some did so by design. Others stumbled upon their professions after trying other roles.
And, given the inquisitive nature of our panel, I doubt this is the final resting stop for any of them. If we were to chart their careers forward, I imagine we would find them taking on new tasks, conquering new challenges. They have all done a lot of growing, but I doubt they are done. So maybe it would be interesting to ask them next time, "What do you want to be when you grow up?" We'll see, we'll see.
For the developerWorks Architecture team --
Paul Dreyfus, Editor
developerWorks
pdreyfus@us.ibm.com
Modifying elegance to cope with reality
An architect allows everything to motivate him: the client, his team, the architecture, the glitches, the problems. I think architecture is more like an attitude, an enthusiasm to construct a software edifice with grace and finesse, but the mundane often makes it less so. Nevertheless, this balance of grace and reality lends a certain sobriety to the architect, who has to deliver a running, well-performing system to the client.
Flashback: I see myself in meetings, drawing on the whiteboard, tackling problem after problem. Along with the team, I trying to balance the forces and constraints of the problem domain using things I know have worked in the past. Patterns? Maybe. I enjoy the rush of the group dynamics--the mentoring and the learning I get every minute as my colleagues describe in careful detail the nuances of a situation: Why this scenario is a bit different and thus we have to modify the elegance of the pattern to cope with reality.
Flashback to coding: Coding is a lonely quest. And a never-ending one. Sometimes a thankless one. Find a bug and...you get comments. If there are no bugs in the final delivery/build, there is no mention of all the grandeur and work you put into that piece of code!
I enjoy programming--although now I do much less and do it in an academic environment. On projects, I am no longer coding.
Flashback to Hong Kong, 1980: I started coding in BASIC and Fortran. I LOVED to program. Cut to 1995: Java™ programming and the sheer joy of interface implementation and looser coupling. But how should the system be structured?
Even if you have the best code running, you still need a structure that can hold its own against the onslaught of nonfunctional requirements. Thus, you need the ability to balance conflicting constraints, to make decisions in light of slight nuances of the current situation.
I tend to subscribe to the school of thought that "patterns generate architectures." You start with a blueprint--a set of base patterns--and you extend and customize that based on the tug of reality at your coattails. This balance between best practice and reality has certain QWAN (Quality Without a Name) and I love it.
I enjoy being an architect. :-)
Travels with a rogue
It's not so much that I decided to become an architect; rather, my career has been one of growing up alongside that thing which we can now label as architecture.
In the beginning--well, for much of its history, and even through today--we as an industry didn't "architect." We just wrote programs, and whatever architecture there was emerged accidentally.
I wrote my first program when I was 14 (in Fortran, and I certainly didn't know much about good design, much less architecture). In college (first the Air Force Academy and then the University of California at Santa Barbara), I was exposed to many people who were at that time formulating their early thoughts about deep design: David Parnas, Mary Shaw, Tony Hoare, Edsger Dijkstra, and others. In my early twenties, I was a project engineer and then a project manager for some fairly large (even by today's standards) real-time distributed systems in support of the country's military space program.
As I left the service in 1982 and was with Rational® at its beginning, I was heavily involved in the Ada program. I spent much of my time traveling the country, working with contractors and military programs to help them apply best practices of software engineering with this emerging language.
I've always been a rogue who traveled where the science took me. Increasingly, I found myself being asked by organizations in the commercial world to help them in a similar manner, and so I began to drift away from Rational's core business to spend my time in this larger domain. Around this time also, I wrote my first papers on object-oriented design and began work on the third of my books on that topic--all of which were little more than summaries of the experiences I had with these projects. I also spent time with Bjarne Stroustrup (the inventor of C++; we even went on a national lecture series together) because we found that his approach to language design and my approach to system design resonated.
Throughout that time, I still programmed: I wrote a prototype of what became Rational Rose in ObjectPascal (on the Mac) and then a second, more complete one in Smalltalk (on a PC). Dave Stevenson and I were the architects for the first Rational modeling product (written in C++, which was a break for Rational, as we'd done every other product in Ada before that).
Once those products gained traction in the market place, I returned to my role as an architect and architectural mentor for a number of our largest customers. During this time, I was heavily influenced by the work of Philippe Kruchten, who led our early process work among other things and was one of the lead architects for the Canadian Air Traffic Control System. He was also involved in the IEEE standard on architectural description.
 |
I am trying to help people remember that the "A" in "SOA" means "architecture."
-- Grady Booch
|
|
In more recent years, Kent Beck and I assembled a patterns workshop that morphed into the Hillside Group that today continues to be the center of gravity for pattern literature. I became a founding board member of the World Wide Institute of Software Architects (WWISA) and more recently, the American Institute of Software Architects (AISA), both working to advance the practice of software architecture.
These days, now that Rational has been fully absorbed into IBM, I'm back to my roots with architecture. I'm interested not just in IT architecture but rather general architectural principles for every domain of software-intensive systems. There is still much we don't know about architecture--what it is, what it is not, how best to represent it, what patterns exist at the architectural level. So I'm spending much of my time learning, both by doing and studying. In the doing realm, I continue to be called in as an architect and architectural mentor to a number of our customers and even among organizations who are not our customers yet. And in the area of studying, I'm working on the
Handbook of Software Architecture, the goal of which is specifying the architecture of a variety of interesting software-intensive systems. I'm engaged with the architecture folks at the Software Engineering Institute (SEI). I'm tracking the work in systems engineering by Murray Cantor. I am trying to help people remember that the "A" in "SOA" means "architecture," and I'm also engaged with some of the emerging commercial and industrial architectural standards.
Oh, and I still program, mostly in Java, but now I think I finally know how to architect the systems that I program.
Navigating non-Euclidian nightmares
It was my penultimate semester. I was hunched over a desk cluttered with research papers, half-opened books, and endless, scribbled notes, shaping my senior thesis. I was battling this abstract geometric model, trying to articulate its potential impact on computational graphics. My eyes were tired of visualizing arbitrary dimensions, quasi-planes, and abstract mathematical transformations of n-fold spaces. Navigating through this non-Euclidean nightmare, I clearly found myself at this crossroad: theoretical computer science (and a path in academia) or applied computer science (and a path in industry). I chose the latter so decisively that I joined a Fortune 10 bank after graduating.
As an associate consultant at this bank, I was part of a team designing a massively distributed global letters of credit solution. I was thoroughly baptized with formal software development life-cycle methodologies, industry-hardened engineering principles, software product stacks, and a cartload of commercial banking domain concepts. Emboldened by this experience, I forayed to Switzerland and consulted for several banks providing technical guidance in several areas such as electronic document archiving to disparate data integration. The meticulous Swiss engineering and quality focus was insightful, and their eagerness to embrace emerging technologies allowed me to dabble with various innovative products.
| ...I was allowed to lift the hood of the application layers and stare directly at the nitty-gritty of OS kernels and underlying hardware.
-- Sanjay Bose
|
|
By this time, I'd overdosed on banking and joined the R&D department of a global SI to revisit my roots. Here I was allowed to lift the hood of the application layers and stare directly at the nitty-gritty of OS kernels and underlying hardware. I was making modifications to UNIX SVR4--adjusting bootstrap and scheduling algorithms, optimizing device drivers, tuning event and interrupt handling, reverse engineering from machine code, frolicking in components written by my early heroes (Ritchie, Thompson, Joy), teaching x86 and RISC processor internals, tweaking with the then-emerging micro-kernels and real-time operating systems. This experience solidified my understanding of how solutions and applications really run.
Now the dot-com era had started, the world was becoming more object-oriented, and I didn't want to miss the bandwagon. So I became lead engineer for a start-up that was creating a product to solve the real-time integration of heterogeneous, enterprise data sources. I was designing and building the core run-time infrastructure, metadata management, and the data access framework. This place was a serious OO boot camp. My colleagues (most were barely out of school) brought their unadulterated OO indoctrination--I suspected they had Gang-of-Four cereal for breakfast! Well, I became an instant convert and became fluent with OO design, patterns, and techniques and how to apply them with Java and pre-J2EE. Apart from core product architecture, I was wearing multiple hats: selling to customers, providing input on UI tools and human factors, obfuscating the installation binaries, troubleshooting customer deployments, and so on.
Soon I ached for the cadence of a large company and joined IBM. Initially, I was worried I'd be lost in Big Blue machinery but quickly learned that IBM operates like an umbrella VC with numerous pockets of entrepreneurship and innovation. I started as a developer for the WebSphere Application Server product starting with the system management and EJB container components. Following that, I joined an incubator project in IBM Research, NextWeb, to propose and create a syndication framework for Web services, including "on-the-glass" services. This led to various interim standards before finally resting with the OASIS WSRP TC. Concurrently, I was architecting components in WebSphere Portal Server to transition some of these incubated technologies.
By this time, I caught the Web services and pre-SOA bug. I began to provide technical guidance to IBM strategic business partners on how to leverage our middleware portfolio and better accomplish their niche product functionality. As SOA technologies matured, I expanded this coverage to our large IBM customers and bleeding-edge adopters--sharing our technical strategy, shepherding them through architectural pilots, and advocating their issues to our software product teams. Currently, I've further focused and am helping drive the SOA requirements strategy in IBM Software Group by channeling the critical gaps and issues from our worldwide customer engagements into the IBM software portfolio and solution assets.
I have been fortunate to experience various facets of IT and, as I've mentioned before, have honed my meta-learning skills. To this day, whenever my vigor wanes during a techno-philosophical impasse or paralyzing politicking (yes, we do have those in IBM too), to re-energize, I just have to pluck my senior thesis from the bookshelf.
Identifying the important technical details
I decided that IT architecture was right for me because that is the technology area that I felt (and feel) the most passion for. This is the kind of specialty that compels me to research when I do not have any deadlines looming, the one that makes me late for dinner because I cannot stop reading about some new technique. I really enjoy bringing together many different points of view into a cohesive deliverable, tying together seemingly unrelated strings to form more relevant solutions. Architecture highlights the challenge of identifying out of many different technical details the ones that are crucial for the success or failure of a project, the ones that have a direct impact on meeting stakeholders' requirements.
I started my career as a developer, focusing on very specific elements within a much greater software effort; this typically meant that I was mainly involved during the implementation stage, not so much during architecture. The design I did then was mainly "in-the-small," typically within one application. The more I advanced in my career, the more I realized that even if a software building block is constructed with great skill, if the underlying vision and architecture were not accurate the project's chances of success were significantly diminished. So, I started to proactively search for the kind of projects that would enable me to participate more in such activities. This matched my technical inclinations for understanding a solution's "big picture." After some time I started performing the architect's role during projects. The rest is history :-)
It started with FORTRAN
 I would like to think that I planned my career and life, but I have to admit that I did not. My girlfriend and I argue about free will. She believes that free will exists. I think we are a really, really complicated Turing machine that is completely defined by the sequence of inputs. So, I should probably not answer this question. Everyone knows that I will answer it, however. My Turing machine has entered a state that compels me to wax philosophically and endlessly on any topic.
I never saw a computer until I went to college (my sophomore year). Yes, that is how old I am. Actually, I did not see a computer until much later. I saw a terminal when I was a sophomore. I took a class in FORTRAN and found that
- I really loved writing programs.
- I was really good at it.
I am not sure that I am still good at it, whatever it is. I still love the technical aspects of my job: tinkering with code, writing a little PHP, discussing some design choices, thinking about the next big thing. . . . I periodically do site visits and spend all day reviewing and discussing projects. The people at the site comment that I seem to never tire, despite jet lag and the length of the day. They want to know how I do it. Those days are the most fun I have at work, and I love it. Better than coffee.
That's how I decided IT was right for me. What path did I follow? I constantly and still do explore new topics. I follow the path that looks like the most technically challenging and fun.
A solid foundation based on practicing a broad range of IT disciplines
I chose a career path in IT architecture for many of the same reasons as Bobby. I started out maintaining code written by others. Often, the code I was asked to maintain was incomprehensible to anyone other than the person who wrote it. (At least one would hope that they could understand it.) In order to get a better sense of what various aspects of the code were doing, I would rewrite the code so that I could get a better sense of how the system worked. I found (as did my managers and the other, more senior software engineers) that I had a knack for rewriting the software to make it more easily maintainable by others after me.
Over time, as my skills grew and the scope of the projects I was assigned grew broader, I would often find myself working on software in which I recognized areas of duplication of functionality (or nearly so). I would redesign such redundant functionality such that it was contained in a reusable module within the application, reducing the amount of code that had to be maintained and reducing the potential for bugs.
At some point, I found that I wanted to apply these skills on a broader level. I wanted to understand how all these applications I had been working on fit together. I think that is the point at which I decided that I wanted to be an IT architect. The path that I took to ultimately reach my objective took me through a broad range of IT disciplines, including QA testing and operations. I also played a key role in the deployment of a replacement ERP system: That involved a complete overhaul of all of the interfaces between the old ERP system and the satellite applications that were dependent upon it (or vice versa).
All of these experiences helped shape my IT architecture skills. I certainly agree with Bobby, that it is quite important to build a solid foundation of experience operating, maintaining, testing, and deploying software to be an effective IT architect.
Communication on all levels is key to success in this field
My path to an architect is probably different from most, since I left the university as a mathematics major having done a lot of simple computer programs both in high school and at the university. I joined a large retailer after graduating and learned how to build commercial applications using a variety of technologies. I mastered the programming languages and technologies and became a team lead, designer, and teacher. I got bored and decided to change careers, so I went to law school. Upon graduating from law school I was surprised at the number of large companies (non-law firms) recruiting graduating law students. As I pursued some of these interviews, it became obvious that the skills acquired in law school (for example, issue identification and conflict management) were, if mastered, essential for all aspects of leadership. In addition, in my first year of law school I remember one professor stating matter of factly that the school's goal was simply to teach us three things: how to read; how to write, and how to think. These were key lessons.
I took a job with a consulting firm after deciding not to pursue the field of law. I left and joined, for the first time in my career, a small (at that time) computer company, Tandem Computers. My experiences at Tandem gave me a far greater holistic view of why companies bought technology and how they used technology. More important, because of the variety of roles at Tandem, I had to operate as a teacher, consultant, programmer, software engineer, and architect. I found myself needing to not only design and code, but i needed to help determine the proper technologies for a solution and I had to be concerned with usage patterns, quality of service and I had to care for both the needs of the future as well as immediate needs.
I discovered that good architects are benevolent dictators, with strong technical acumen, good writing skills, good oral presentation skills, individuals who can communicate at all levels. I liked this new role. I joined IBM because I met some very bright individuals who were working for very large companies, interacting with CEOs, CIOs, and influencing the technology direction and responsible for architecting major solutions whose successful outcomes were important to the senior executives. I wanted to play in this sandbox--and here I am.
What happens when you stop coding and focus on design and integration
The first five years of my career in IT, I mainly designed and optimized databases as a database geek (we were still called DBAs then) in the retailing industry. This was in the early 1980s (yes, my age is showing too!), and what amazed me was that simple tasks like restructuring a database that had a few million records used to take 2 to 3 days. Things like online reorg and relational databases were not in vogue! When I asked my then-manager a few months into my job, why things took long, when the CPU was idle most of the time, the answer was "That is the way it is. We simply follow the procedures in the manual. This is why you need to be at work on Labor Day weekend so you can fix problems. We only get one chance each year to reorg (for those new to databases, a reorg is usually used to redesign or restructure a database that is already populated with information) our database and get ready for the Christmas peak traffic season."
|
I got a promotion and my boss told me that I would one day be a good architect (whatever that was going to be)!
-- Sridhar Iyengar
|
|
At that time I was fresh out of school. I was disappointed that all the nice computer science theory about parallellism I had learned was not exploited by database systems of that era--at least the database systems I knew. My goal was to design a parallel version of reorg so I did not have to stay all weekend in front of a green screen. That is what led me down the path database design, parallel programming, and multitasking operating systems. When I got the reorg time down from about 2 1/2 days to around 7 hours, I got a promotion and my boss told me that I would one day be a good architect (whatever that was going to be)! Soon I started designing and tuning databases for many customers by becoming a database consultant in a small boutique consulting company, which ended up getting acquired by a larger computer vendor.
The next five years or so I taught customers how to design databases and applications to make the most effective use of CPU resources. This meant talking about application and database architecture--this is what led me to IT architecture. My initial focus on database design led to my exploration of entity-relationship modeling (still a technique used by a majority of database designers). From there, I looked at semantic modeling in the late 1980s, which I thought was really cool, and then object modeling and object databases. Around this time, I was introduced to "metadata" and "metadata repositories"--remember this was the era of AD/Cycle. An interesting convergence of events happened a few years later in the mid 1990s when modeling languages (think UML), metadata languages (think Meta-Object Facility, XML DTDs, and later, XML schemas), and middleware (think CORBA initially, and later, J2EE and .NET and ESBs) started down the path of object orientation and eventually component-based and service-oriented systems.
Somewhere along the way my business card started carrying titles such as "database architect," "object architect," "software architect," "chief architect," and the like. It was one of these years that I was elected to the "architecture board" at the Object Management Group (OMG), an industry standards body that popularized industry standards like Common Object Request Broker Architecture (CORBA), Unified Modeling Language (UML), and eventually Model-Driven Architecture (MDA). I guess people decided I was an "architect" after all, because I had stopped writing code a couple of years earlier but was much more focused on how to make systems work together--the world of tools, application and data integration.
Now, I give talks about how "architectures" can be used together, such as "How to use Model-Driven Architecture and Service-Oriented Architecture concepts together." Designing software tools that work together using open source (primarily the Eclipse and Apache projects) and open standards (mainly from W3C, OMG, and OASIS) based on real customer scenarios is what I do as an architect in IBM these days. I also spend time with our important customers, helping to define their architecture and strategic directions in using tools and middleware. I guess I am still an architect because I am on the IBM Software Group Architecture Board Steering Committee, the IBM Eclipse Review Board, and the OMG Architecture Board.
Needless to say, I am having a ball and will be playing in the field of architecture for a few more years. You could say I am addicted to architecture now--especially being around so many prominent industry architects inside and outside IBM.
Do everything
Although I have the word architect in my title, I have never been comfortable being called an architect. Instead I have a stronger affiliation with what Kent Beck writes about Extreme Programming: Don't force team members to specialize and become analysts, architects, programmers, testers, and integrators--every XP programmer participates in all of these critical activities every day.
Being able to do everything is what makes IT fun. You can conceive a new idea, develop it, show it, get feedback, and improve on it. And you can do it anywhere, anytime. What other profession gives you such degree of freedom to innovate?
So look for any opportunity to develop all these skills. Don't be afraid to pick up any technologies and write that "hello world" application. There is always something new to learn and try.
Understanding the totality of the problem
As a young lad, I was often confounded and perplexed with what made seemingly the simplest things work. Why did my bicycle have so many moving parts? Why did my bike have a chain attached to a pedal? And what would happen if I attached the small engine from my lawn mower to the back of my bike. Would the bike move on its own? What are really the best practices for riding a bicycle downhill without holding on to the handle bars? Little did I know, this was the beginning of a fascinating adventure into the world of architecture.
I, like many of my colleagues, never endeavored to be an architect. But like them, the path to becoming an architect seemed to be a natural evolutionary branch along my IT growth curve. I began my career in the late '80s working in the IBM AIX development lab. My concept of architecture at that time was all about the speeds/feeds and functionality of AIX. I didn't really understand how my role as a C and C++ UNIX coder and tester could actually help customers implement and deploy mission-critical applications. Many of those applications serve as the catalyst and key enabler to what we called the "capitalistic society."
After laboring in the AIX development lab, I took a job as an IT specialist working with customers trying to implement client-server systems. Shortly after this endeavor was the beginning of the dot-com wave and the advent of what many called the Java evolution. After changing loyalties, I took my first job that had "architect" on my business card with the Sun Microsystems JavaSoft organization in the mid-90s. Between now and then, I've swung back and forth between the IT specialist roles--practitioner and IT architect.
|
Architecture has more to do with understanding what the problem is than what tool and technology I should use to solve it.
-- Calvin Lawrence
|
|
Although I like the term "practitioner" much better than architect, "architect" seems to be more widely accepted and appreciated. We architects get excited about technology because we understand how technology enables architecture and how architecture enables IT. As an IT specialist, I typically knew the solution before I knew the problem. For example, I had a Java hammer in my bag, and regardless of what size nail or screw (problem) I had, I could solve it with my Java hammer. That philosophy served me well for a time. In the late '90s and early 2000s, I finally realized that regardless of how advanced my programmer skills were, I rarely made an impact on the bottom line. Then it hit me, "Architecture has more to do with understanding what the problem is than what tool and technology I should use to solve it."
The rule of thumb I have taken from all this: Understanding the totality of the problem will help you determine what technology to use to solve it.
Learning new areas beyond my comfort zone
When I was in college, I did not really think I was going to be an architect. I think it was one of the paths I ended up taking since I tended to shape or design most of the components I--and some of my team--worked on. In every role I have played in my career--programmer, system admin, consultant, middleware products specialist--I tend to ask the types of questions pertaining to why I am doing what I am doing and whether it really made sense to do something the way I did it.
I have worked with some really bright people and have learned a lot about how to decompose a large complex problem into smaller, doable units with an eye kept on the big picture. I think that is one of the key aspects in an architect's role that helps solve tough problems and execute large projects. I love to approach a problem domain from as many angles as possible, to find the best solution. I am fairly hands-on, and I love to play with new software, new architectures, new domains, new technology--and apply them to my projects. It is always a continuous learning process, and I enjoy it.
With the number of ways learning has been made easy--online classes, self-study books, Web sites, and demos among others--picking up new technology is not hard these days. The key is how well one applies it to real-life problems--that is what differentiates a good architectural decision from another. It is very challenging, and the only effective way that I have learned to do this is by constantly engaging in new projects and learning new areas beyond my comfort zone.
The value of designing before attempting construction
I have always been interested in designing and building things. Growing up, I really enjoyed the process of designing (architecting) experiments for the science fair and other hobbies like electronics. I acquired an appreciation for putting pen to paper and drawing up designs for my projects and hobbies. My father, a fairly well-known immunologist and a consummate perfectionist, instilled in me the value of first designing [architecting] solutions before attempting construction.
|
The real first job I had was working on a contract for the government in the mid '80s at a time when computers were a bit of a luxury.
-- Andras Szakal
|
|
However, I followed a somewhat circuitous path to becoming an IT architect. I majored in biology and computer science as an undergraduate. I endeavored to leverage a multidisciplinary approach to basic research either in the field of microbiology or immunology (following in my father's footsteps). The real first job I had was working on a contract for the government in the mid '80s at a time when computers were a bit of a luxury. Fortunately, my client had the funding to foot the bill for several PCs. I convinced the lab director to allow me to use the computers to develop programs used to convert the extremely time-consuming and error-prone hand calculations necessary to produce the results of our assay.
After several years working in the lab on brain biochemistry, I decided that my passion lay with computers and designing systems. I returned to school and completed my Masters degree in computer science. Fortunately, I was able to step out of graduate school into an opportunity to participate in producing the architecture for a first-of-a-kind telecommunications provisioning system--once again for the government. (It just keep sucking me back in.) Eventually, the system we developed would provide services for every agency in the government. Those five years I spent working on the telephone-company-in-a-box provided me with the experience necessary to mentor other engineers and eventually become a distinguished member of the staff.
I left the telecommunications project when telecom-merger-madness started and joined IBM as an architect on the component broker team. The rest is history. Ultimately, I found that IT architecture afforded me the opportunity work across organizational boundaries and produce system architectures that truly impact the customers business.
Start at the bottom and work your way up
I partially answered this in my contribution to the third installment in this column, "Understand the pieces and how they fit." Architecture means understanding all of the parts involved and how they fit together. So how can you learn to do that? How did I? (Assuming I have!)
I started out in software testing, if for no other reason than that's where I could get a job in a group writing software (even if I wasn't writing it). Testing taught me to think about questions like: How do you know when software is working right? If a feature wasn't working right, how could you tell? What's most likely to break and how can you break it? Turns out those are good thoughts for a tester. Also turns out it helps you get in a mindset for creating good software.
My first programming job was performing maintenance on existing code. This really taught me how to write code that was (or wasn't) maintainable, and how to design for reuse. Code is meant to be read and understood by two audiences:
- The computer executing the code
- The developers maintaining the code
I saw a lot of code that addressed the first audience but totally ignored the second audience. To this day I strive not to make that mistake.
So understanding how to test and maintain code helped make me a better coder. Being able to code helped me learn how to design components and frameworks and how to hide an implementation behind an interface. Having to test my own code made me write code that could be isolated as reusable components and tested as units. Then I started programming for different parts: database, messaging, workflow, etc. Even the application had parts, like EJBs and servlets. With this experience, I started to see applications as big parts working together, encapsulating the details of how each part is implemented. As I started to think of applications as those big parts, layers of distribution, and the specialized engines they run in, I started thinking like an architect.
So my advice is to start at the bottom and work your way up. Master each level of capability; you'll need that foundation when you take on your next level of incompetence. Architects who lack this foundation tend to struggle.
|
Architecture is .... the level of involvement that enables me to most productively have the most positive effect on a project.
-- Bobby Woolf
|
|
Architecture is right for me because it's the level of involvement that enables me to most productively have the most positive effect on a project. That used to be (and sometimes still is) testing, then code maintenance, then development, then design. Maybe one day it'll be something else. (Management? Probably not.) But for now, architecture is the best way for me to help get the project done.
In that previous column, David Jackson, Grady Booch, and Jenny Choy advised (respectively) "Communicate and facilitate," "Communicate and listen," and "Make connections." Those are all good pieces of advice, too, and not necessarily something we learn as engineers. You can have great ideas about how to build an application, but if you can't communicate those ideas to a team and persuade them to follow your plan, the best you can hope for is to be stuck doing all of the work yourself.
About the experts
Ali Arsanjani
Ali Arsanjani, PhD, is Chief Architect for the SOA and Web Services Center of Excellence within IBM Global Services, specializing in harvesting and developing best practices for the modeling, analysis, design and implementation of SOA and Web services. He leads the internal IBM worldwide SOA and Web Services Community of Practice (4000 members) and is the principal author of the (Service-Oriented Modeling and Architecture) SOMA method for SOA. He is currently focusing on SOA Tooling with support for Modeling (SOMA), Assessments, Strategy and Planning, Governance, Architecture and Realization and their practical application to engagements inside and outside of IBM. Read his blog, Best Practices in Service-Oriented Architecture.
Grady Booch
Grady is an IBM Fellow who has served as architect and architectural mentor for numerous complex software-intensive systems around the world in just about every domain imaginable. Grady is the author of six best-selling books and has published several hundred articles on software engineering, including papers published in the early '80s that originated the term and practice of object-oriented design. Read his blog, Software architecture, software engineering, and Renaissance Jazz.
Sanjay Bose
Sanjay Bose, program director for the SOA Requirements Hub, works for the IBM Software Strategy division and leads the Enterprise Integration Design Center to identify IBM Software portfolio requirements, and develops solution components and assets by engaging enterprise clients and IBM Software product development laboratories. He has more than 12 years of IT industry experience, primarily focused on creating product architecture and design, articulating technical strategy, and designing enterprise application systems using distributed technologies. His areas of expertise include SOA, Enterprise Service Bus (ESB), Web services, Java™ 2 Platform, Enterprise Edition (J2EE), and e-business technologies. He has coauthored the book, SOA Compass, and has published articles on IBM developerWorks and Systems Journal. He lives and works in Pittsburgh, Pennsylvania, and his spare time is spent with philosophical ramblings, books, movies and his Sony PlayStation. Read his blog, SOA, ESB, and beyond.
Jorge Diaz
Jorge Diaz is a solution architect with IBM Software Services for WebSphere. He focuses on delivering strategic and tactical architectures in the areas of middleware and distributed systems integration, working throughout the Americas and Europe. Mr. Diaz works closely with large customers, helping them to adopt Services Oriented Architecture using a variety of technologies, including Web Services.
Donald F. Ferguson
Donald Ferguson is one of 53 IBM Fellows (IBM's highest technical position) in IBM's 200,000 employee technical team. Don is also the Chief Architect for IBM Software Group. Don chairs the SWG Architecture Board, which oversees the architecture and integration of WebSphere, DB2®, Lotus®, Tivoli®, and Rational® products. Don was the original Chief Architect for the WebSphere family of products. He joined IBM Research in 1985. His interests include raising and playing with his children, distributed systems, simplifying application development, systems management, Web services, transaction processing, performance and karate. Read his blog, Middleware and tools.
Christopher Ferris
Chris Ferris is a senior technical staff member in IBM's Software Standards Strategy group. He has been involved in the architecture, design, and engineering of distributed systems for most of his 25+ year career in IT and has been actively engaged in open standards development for XML and Web services since 1999. Chris currently chairs the WS-I Basic Profile Working Group, that is responsible for the development of the WS-I Basic Profile. He represents IBM on the W3C XML Protocols WG, where he serves as editor. He represents IBM on the OASIS WS-RX TC. He is a former elected member of the OASIS Technical Advisory Board (TAB). Additionally, he is an author and editor of the WS-Reliable Messaging specification and the IBM RAMP profile. Read his blog, Web services, distributed computing, and interoperability.
Kerrie Holley
Kerrie Holley is Chief Technology Officer for IBM's Services Oriented Architecture and Web Services Center of Excellence. His expertise includes software engineering, architecture, and translating business requirements into designs for network-centric distributed solutions.
Sridhar Iyengar
Distinguished Engineer Sridhar Iyengar leads technical strategy for the IBM Rational Software development team. He sits on the OMG Architecture Board and Board of Directors where he oversees the evolution of Model-Driven Architecture standards.
Christina Lau
Christina Lau is an architect on the On Demand Development team. Her current projects include creating Pattern Solutions using Rational Software Architect and piloting business innovation and optimization functions. Christina is a Senior Technical Staff Member and a member of the IBM Academy of Technology. She is also a coauthor of Introduction to IBM Rational Application Developer.
Calvin Lawrence
Calvin Lawrence is an executive architect on the IBM Software Group Emerging Technology team. His responsibilities include advancing strategic IBM architectures, technologies and products in support of key strategic initiatives and ensuring the success of customer implementations using IBM technologies. He is former Chair of IBM Software Group Worldwide Technical Leadership Council.
Sridhar Sudarsan
Sridhar Sudarsan is a senior IT architect with IBM Software Services for WebSphere. He has led enterprise architecture solutions for several customers worldwide, including large companies in the finance, public sector, automobile, and SRM industry verticals. He is a cocreator of the batch programming model in J2EE that is now a component in WebSphere XD, and now he's evangelizing it with customers and building a practice around the technology. He is currently leading a large scale SOA Center of Excellence at a large insurance company.
Andras Robert Szakal
Andras Robert Szakal is chief architect for the IBM Federal Software Group and is a distinguished engineer and Senior Certified IT Architect. He is also serves on The Open Group Board of Directors.
Bobby Woolf
Bobby Woolf is a member of IBM Software Services for WebSphere, consultants who help customers achieve success with WebSphere products. He is a coauthor of
Enterprise Integration Patterns
and
The Design Patterns Smalltalk Companion. Read more at Bobby's blog on developerWorks.
Resources Learn
Get products and technologies
-
Build your next development project with
IBM trial software, available for download directly from developerWorks.
-
Get a collection of architecture resources from
IBM IT architecture kits, available for download directly from developerWorks.
Discuss
About the author
Rate this page
| 
