Architecture Journal Profile: Faisal Waris

In this issue, we catch up with Faisal Waris, an architectural consultant at Ford. The Architecture Journal asks him about the 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 for Synova 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 workgroup that deals with business-to-business (B2B) messaging. AIAG stands for the Automotive Industry Action Group, a standards body for the automotive supply chain. It has a fairly large membership consisting of various OEMs and suppliers.

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

FW: The team I work in is part of the Enterprise Architecture Group, which takes on various roles. Firstly, we are similar in some respects to a research organization, looking at emerging technologies, performing proofs-of-concepts, and experimenting with software and devices to figure out if something will add value to Ford. Then, we engineer that technology for the mainstream application teams. The other role of the group is about setting standards, which can include defining standards and best practices around Service-Oriented Architecture (SOA) and other architectural topics. SOA governance is a major area that we’re currently working on. This involves creating processes, frameworks and usage guidelines for enterprise-wide products and services that are being introduced into Ford. We also help application teams implement SOA Web services and troubleshoot when things go wrong.

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

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

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

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

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

FW: AIAG is more than just an action group; it is both a vertical for the supply chain and a standards body. It brings together suppliers and OEMs, and gets them working together on common problems. There are engineering type standards, and there are process standards, but more and more they are getting into eCommerce type standards—these are standards related to the exchange of information between suppliers and OEMs. I am part of the group that works with those sets of standards, and our goal is to enable seamless integration between automotive supply chain partners by defining standard business processes. A standard process could be something like inventory management process—say Kanban, MinMax—Quality or Warranty processes. We then take these processes and perform proof of concepts using Web services and related technologies (such as ebMS). We demonstrate that many implementations of a business process (with interfaces defined by a set of WSDLs) can interoperate securely and reliably. Our goal is to promote this in the industry.

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

FW: Sync is a partnership between Microsoft and Ford, and is one of the first applications of the Microsoft Automotive PC in production use. Sync is very interesting. In its current context, Sync provides services related to entertainment, voice recognition, operating the phone, and media devices. One way to think about it is as a general purpose computing platform in the automobile. With this paradigm, the sky is the limit; there are a lot of possibilities as to what you can do with it. Of course, there are challenges related to what you can put in a car from a user perspective because of many considerations. But a new world is beginning and we are very excited to be a part of that.

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

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

AJ: We find that many readers of the Architecture Journal are aspiring architects, perhaps senior developers looking for the next step 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 advice would you give a would-be architect today?

FW: I think that there’s a gradual process where someone transitions from developer to development lead, and then on to architect. There are also very different types of architects. At Ford we have infrastructure architects, solution architects, and even specific architects like SOA architects. If you are an aspiring architect, I believe that being current with the literature is key because being able to understand how to take a set of technologies 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 reading just 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 my sleeves up and tweak with code. I’ve found that’s this is really beneficial. A lot 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 understand the whole picture and sometimes you have to understand at a very deep level to be able make the right kind of decision. My advice would be to play around a lot with new technologies and experiment. You don’t have to write production applications, but what you can do is experiment so that you have a sense of what something can do, what are its limits, what are its capabilities, and that overall gives you a much better perspective as to what will work and what won’t work.

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

FW: That’s a hard one to answer! I can’t actually remember anything that I really regret. I have had many chances to go purely into management, and I have steered myself clear of that. I’ve always had one foot in the technical area. I think that has helped me to be where I am today. Being in this 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 move into management, or do you stay in an architect consulting role, or how do you move forward? That’s one of the things that I need to figure out.

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

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

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

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

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

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