In this issue, we catch up with Faisal Waris, anarchitectural consultant at Ford. The Architecture Journal asks him aboutthe role, what some of his challenges are, and his views on architecture.

AJ: Faisal, can you tell us a little about yourself?

FW: I am a consultant at Ford Motor Company, working forSynova Corporation. Essentially, my main role at Ford is as an SOA architect,and I have been here for four or five years. I am also the co-chair of an AIAG workgroupthat deals with business-to-business (B2B) messaging. AIAG stands for theAutomotive Industry Action Group, a standards body for the automotive supplychain. It has a fairly large membership consisting of various OEMs andsuppliers.

AJ: Four or five years at Ford as an SOA architect soundslike a fascinating role. Can you elaborate a little more on your work?

FW: The team I work in is part of the EnterpriseArchitecture Group, which takes on various roles. Firstly, we are similar insome respects to a research organization, looking at emerging technologies,performing proofs-of-concepts, and experimenting with software and devices tofigure out if something will add value to Ford. Then, we engineer that technologyfor the mainstream application teams. The other role of the group is aboutsetting standards, which can include defining standards and best practicesaround Service-Oriented Architecture (SOA) and other architectural topics. SOAgovernance is a major area that we’re currently working on. This involvescreating processes, frameworks and usage guidelines for enterprise-wideproducts and services that are being introduced into Ford. We also helpapplication teams implement SOA Web services and troubleshoot when things gowrong.

AJ: Many of our readers may be implementing SOA. Whatrecommendations would you share with them?

FW: One of the debates we have here—and, I believe, onethat’s probably happening in most other places—is the question, What is aService? What does a service consist of? If I have an FTP job, is that aservice? Does the word service only describe a Web service, or does a servicein AJAX count also? I think a lot of companies, including ourselves, strugglewith the definition. We have decided to adopt a very pragmatic way to deal withit. To resolve this we use the OASIS definition. You can go to OASIS andactually get that from their Web site. We decided to use that as our definitionbecause a lot of people worked on it, so it’s kind of a consensus view on howto define SOA. It’s still a very generic definition, but what it allows you todo is to tailor it for specific use. If you think about it, almost anything canbe a service, but if you want to have an architecture that connects all ofthese services together in a uniform way, deferring to the OASIS definition, thenyou have to start to think about what you really want a service to be. We foundthat if you want uniformity across your services then the first step is toestablish a certain set of standards and protocols.

AJ: You mention a focus on governance. Do you thinkmany organizations today struggle with governance?

FW: I think it depends on the maturity of the organization—orthe maturity of SOA in the organization. If you are just starting out, then heavyduty governance is not what’s really needed. What’s needed at that time ishelping and nurturing the nascent SOA in an organization. This can include SOAevangelism, talking to your application teams, and explaining concepts and howthings get done. After a certain point in time—when everybody is comfortableand services are being built—then you can step back and put on more of agovernance hat. As an organization we’re now making this transition. We havedone the evangelizing, and SOA has become accepted. We are now in the phase wherewe need to start thinking about how we manage all of that, making sure theright services are being built, avoiding duplication; given that we havedifferent application teams with different points of view, how do we broker theright service so we have the right consumers and the right providers and theright set of interfaces.

AJ: You also mentioned co-chairing an AIAG workgroup.Can you give the readers a little kind of background on AIAG, especiallyrelated to the mission of the group?

FW: AIAG is more than just an action group; it is both avertical for the supply chain and a standards body. It brings togethersuppliers and OEMs, and gets them working together on common problems. Thereare engineering type standards, and there are process standards, but more andmore they are getting into eCommerce type standards—these are standards relatedto the exchange of information between suppliers and OEMs. I am part of thegroup that works with those sets of standards, and our goal is to enable seamlessintegration between automotive supply chain partners by defining standardbusiness processes. A standard process could be something like inventorymanagement process—say Kanban, MinMax—Quality or Warranty processes. We thentake these processes and perform proof of concepts using Web services andrelated technologies (such as ebMS). We demonstrate that many implementationsof a business process (with interfaces defined by a set of WSDLs) caninteroperate securely and reliably. Our goal is to promote this in theindustry.

AJ: The current issue of the Journal is about mobileapplications and devices. Some readers may have heard about Ford’s new Syncproduct. Could you tell us a little about that?

FW: Sync is a partnership between Microsoft and Ford, and isone of the first applications of the Microsoft Automotive PC in production use.Sync is very interesting. In its current context, Sync provides servicesrelated to entertainment, voice recognition, operating the phone, and mediadevices. One way to think about it is as a general purpose computing platformin the automobile. With this paradigm, the sky is the limit; there are a lot ofpossibilities as to what you can do with it. Of course, there are challengesrelated to what you can put in a car from a user perspective because of manyconsiderations. But a new world is beginning and we are very excited to be apart of that.

AJ: How do you see the role of software in theautomobile evolving over the coming years?

FW: Ford is obviously thinking of many different areas, someof which I can’t cover in this interview for confidentiality reasons, but ageneral purpose computing platform in the car opens up a lot of dreams andpossibilities. There is a potential for providing many services inside the carthat can operate on voice recognition especially one that can perform well inan automotive environment.

AJ: We find that many readers of the ArchitectureJournal are aspiring architects, perhaps senior developers looking for the nextstep in their career, and thinking about what they need to become an architect.As someone who has been doing this role for some time, what kind of advicewould you give a would-be architect today?

FW: I think that there’s a gradual process where someonetransitions from developer to development lead, and then on to architect. Thereare also very different types of architects. At Ford we have infrastructurearchitects, solution architects, and even specific architects like SOAarchitects. If you are an aspiring architect, I believe that being current withthe literature is key because being able to understand how to take a set oftechnologies and stitch them into a solution requires fairly broad knowledge,and fairly current knowledge of what’s out there. I have to do a lot of readingjust to keep up with everything that’s going on. I’m also more of a hands-on architect,so even though I am playing an architecture role I like to go in and roll mysleeves up and tweak with code. I’ve found that’s this is really beneficial. Alot of architects distance themselves from doing any kind of hands-on work,which can be a mistake because you really can’t architect unless you understandthe whole picture and sometimes you have to understand at a very deep level tobe able make the right kind of decision. My advice would be to play around alot with new technologies and experiment. You don’t have to write productionapplications, but what you can do is experiment so that you have a sense ofwhat something can do, what are its limits, what are its capabilities, and thatoverall gives you a much better perspective as to what will work and what won’twork.

AJ: One of the questions we always love to ask thepeople we interview is “What’s the one thing that you regret most in yourcareer, and what did you learn from it?”

FW: That’s a hard one to answer! I can’t actually rememberanything that I really regret. I have had many chances to go purely intomanagement, and I have steered myself clear of that. I’ve always had one foot inthe technical area. I think that has helped me to be where I am today. Being inthis position I do think there may be a limitation that I start to run into,and the question can be how do I advance in this position? Should it be a moveinto management, or do you stay in an architect consulting role, or how do youmove forward? That’s one of the things that I need to figure out.

AJ: Related to your career, what do you hope toaccomplish in the next few years and over the long term?

FW: One of my personal quests is to establish a new way ofdealing with B2B messaging. If you look at what we have today in terms ofmessaging, it is mostly Electronic Data Interchange (EDI). There’s some XMLbeing implemented, but if you look at it, it is still mostly EDI over FTP. Mypersonal quest is to enable B2B Web services, and I believe we have all of thecomponents out there. We have the WS-* specifications that work well in B2B space.For example, we have WS-Addressing for asynchronous messaging, WS-ReliableMessagingfor robust delivery of messages, WS-Atomic-Transaction for transactions,WS-Security and WS-SecureConversation for security, and so on. Many of thetoolsets are now implementing these standards, so one of the things that I amworking on here at Ford and at AIAG is to establish these as the new standardsfor B2B messaging. Of course, it’s very hard given the large installed base ofexisting technologies—but slowly, we start to see people recognizing the valueof exchanging messages with XML because you can do a lot more with it. UnlikeEDI, many aspects of XML messaging can be managed just by leveraging metadata(such as XML Schema, WSDL, WS-Policy, etc.). Plus, you can create robustintegrations (through reliable messaging), which is difficult with somethinglike EDI. That’s my personal cause, so it’s very rewarding and exciting. Theother area of technology I am personally interested in is the semantic Webtechnologies. Now this may be getting a little old at this time—I think it hasgone over the “hype curve” and may even be in the

“trough of disillusionment” —but when I work withinformation, I see how it can be managed better, and I always go back to thecapabilities promised in the vision of the semantic Web. I hope that this needwill be recognized by others and maybe there’ll be a resurgence. At this pointI am happy with what I am doing and very, very busy, so I haven’t had much timeto think about the long term. I definitely like the architect role and I don’tknow whether I want to grow out of it any time soon.

AJ: Faisal, thanks for sharing some of your insightsand thoughts!

If you would like to nominate someone who would make a goodcandidate for the profile in the next issue of the Journal, please contact the editorsat editors@architecturejournal.net.

This article was published in the Architecture Journal, a printand online publication produced by Microsoft. For more articles from thispublication, please visit the Architecture Journal Web site.