Enterprise Initiatives

A little off topic today.

Each evening I help my kids with their homework. They are both very capable with computers. My daughter has been blogging about her pets since she was 8 (she is 10 now). She creates blog entries complete with multi media with no assistance from me. Other than creating the Blogger template for her, all of the work is her own. My son is the wizard of Wikipedia which he discovered on his own a few years back. The fact that my kids are computer savvy gives them a huge advantage when it comes to learning.

For example, my son has a weekly technology project where he must report on how certain technologies work. Like me, he is fascinated by how things are manufactured. So each week we pick an item that we are familiar with and he Google's it. Then we find a video on the manufacturing process like the one below about how bubble gum is made.



This is so much more effective than how I had to learn. I was forced to use either an outdated encyclopedia that my parents purchased or I had to go to the town library. Neither of these experiences offered rich media options. I often had to perform a ton of reserach to get the desired knowledge in order to write my papers. My son and I are able to knock these weekly assignments out in a half hour. At the same time he gets to see the actual manufacturing process in the video which enhances the learning experience. Then he notices similar videos and starts learning how marbles are manufactured.



It is so obvious to me that this generation can consume large amounts of pertinent information in short periods of time. My kids are very up to speed on the current election process and even know who the Governor of Florida is. I am not sure I knew who the governor of NY was when I grew up there in high school. This is the beauty of Web 2.0 and Internet technologies. The whole ranking, tagging, and social networking processes that are taking place are allowing my kids to learn about the world around them.

Here is another great example. My daughter gets assigned a science project. So I am prepared to carve out numerous hours each night to help her get this done. Instead, I see here collaborating with classmates on Google Talk and exchanging links and images. She would draft a story board on paper, scan it, and send it to her classmate. I was floored. She completed the entire project without my help using free collaboration technology on the web. And she's 10 years old! So I ask myself. Are you smarter than a 5th grader?

Tomorrow at 4pm I am presenting at the annual EDM Summit in Orlando on the topic of Business Intelligence as a Service. Check out the presentation below.

This presentation is based on a real life project that I once worked on. We had a scenario where the business had a very complicated set of business rules required to determine what inventory was available to sell. Inventory for a loyalty marketing company is very dynamic and is not a physical thing like a widget. Instead it is a data mining exercise comprised of many "What-if" scenarios.

The old way of doing things was to get data from many different sources, some from systems, some from spread sheets, and some from somebody's head, and go through an ugly and error-prone process to determine what was available to sell. The process took many days which puzzled the customer why we couldn't tell them right away if we could run the program or not. Through some analysis, we defined new and improved business processes and data services that would allow our sales people to enter numerous parameters on a new web UI and let the systems return information to the screen with potential sales opportunities.

When the designers brought their solution to the architecture team for review we saw a huge opportunity to change the approach that was being recommended for the user interface. The designers were Java guys so naturally they recommended a Java web based UI (which infuriated the .Net community). But as I looked at the multiple screens that they story boarded it became obvious that building a what-if type UI was not best served by building proprietary code. Business Intelligence tools make a living doing just that. So I put a hold on the design and recommended that we brought in our BI partner for a proof of concept.

To make a long story short, we proved with our BI partner, that we could leverage the BI tool to create a robust what-if style GUI which we could talk to all of the layers of our SOA (see slides for details). In other words, we abstracted the BI tool as our presentation layer. What that gave us was all of the bells and whistles that come with BI tools like:

1. Flash enabled output
2. Subscription services
3. Mobile capabilities
4. Alerts
5. Great scalability
6. Logging
7. and much more

All of these things I mentioned above were out of the box features of the BI tool that we did not have to code in Java. In fact, we offered to the business a much more efficient solution. Instead of submitting data and reviewing rows on the screen, we offered to automate the business rules and allow them to subscribe to categories. This means that they only needed to go to the system to tell it what to look for and the system would alert them when categories were available. Now they could go into a sales meeting knowing in advance what was available to sell. When certain categories became available they could get an alert and immediately schedule a call to the appropriate customer. A future step could be to tie the alert into the CRM system.

So the key point to this story is that you can leverage BI as an abstracted layer within your SOA which will help maximize the value of your existing BI investment.

I just read Dave Linthicum's post on SOA World titled Should you Fire your CIO? This is a continuation of a discussion that has been brewing in the blogsphere for the past few months that started after the Burton Group commented that a new CIO was often a key ingredient for some successful SOA implementations.

To successfully implement enterprise wide SOA initiatives, strong leadership is required at the top of IT. The person must have integrity, creditability, technical and business know how, and must be able to lead the organization through the resulting shifts in cultural values. The problem is, as Dave points out in his article....

....in many organizations the role of CIO has resolved itself as the person who keeps things running, not the agent of change.

I call this the old "Keeping the Lights on Mentality". When IT stops being an enabler and simply acts as a cost center or a "necessary evil", then entertaining new projects that leverage one of Gartner Top 10 strategic technologies is unrealistic and doomed for failure or hardship at a minimum. Why? Because this mentality is reactive and sometimes even defensive. This mentality also does not encourage investing in the future whether that is in training employees, establishing and investing in architecture, or addressing problems with long term solutions. Instead, people are rewarded for quick fix fire fighting heroics and at the end of the day it is the user community that suffers. The users get band-aids on top of already outdated systems and are often forced to work in ways in which the technology and systems dictate, instead of the other way around.

It gets worse for the employees in an IT department in charge of "keeping the lights on". Their resumes become stale as their skills are not updated to reflect the newer technologies that innovative companies seek. The reactive nature of the culture can squash innovation and people who have valid solutions may not bring them forward because it would require more than a quick fix. In the end these types of shops become like an assembly line in nature where people clock in, work their shift, and clock out. This is not what must of us envisioned when we enthusiastically enrolled in IT related curriculums in college back in the day.

The key business driver in a "keeping the lights on" shop is minimizing costs (usually over anything else). Which makes me wonder why more shops in this mode do not go down the outsource IT path. If lower cost is so important and large innovative initiatives are typically out of the question, why not radically lower the cost by outsourcing IT? I am not recommending that IT shops do this, instead I recommend that IT shops become good business partners and enablers of business success. But if I was a CEO or CFO and my IT's sole purpose was to be a cost center to keep the lights on, I would try to drastically reduce that cost. After all, keeping the lights on is not a core competency of most businesses. It is a necessary evil. Having hordes of full time staffers and paying for their benefits, stock options, and bonuses just to keep the lights on is not smart business. I know my view here will not be popular with most IT folks. I am not down playing anybody's abilities here. All I am saying is that if we don't need our staffs to be innovative, proactive, and be advocates of our business partners and instead just want to the staff to think short term, there is a much cheaper model out there.

So to answer Dave's question, if the business wants IT to help the business achieve its mission by being proactive and innovative and IT is simply keeping the lights on, the answer to his question might be yes. If the business simply needs a low cost IT cost center, the answer may be to evaluate the outsourcing model. Keeping the lights on as a core IT function and doing it at a high cost is just not good business. That's my 2 cents.

Disclaimer: In no way is this article referring to or targeting any organization or individual that I have been associated with in my career. This is a generalized view that combines my own experiences with the experiences of thousands of other IT professionals that I have talked to, read about, or researched throughout my 20+ years in IT.

Packt Publishing recently asked me to review a copy of Michael Havey's new book, SOA Cookbook. I finished the book yesterday and really enjoyed reading it. This book is made for technical folks, so non-technical managers and drag-n-drop programmers should not waste their time. Michael Havey takes a really neat approach in this book to assist architects and developers to understand the concepts of SOA and process modeling. In each of the nine chapters, Michael discusses pertinent patterns, use cases, or disputes and then offers very clear and easy to understand examples of what the resulting models would look like. He also goes one step further and shows specific examples within each of the following vendor stacks (IBM, BEA, Oracle, and Tibco). I find this extremely helpful for technicians who are modeling processes in an SOA for the very first time. He even provides a URL
to download the sample code.

One of the most important points in this book and one that I totally agree with is that the typical three layer SOA stack that most vendors offer is "unmistakenly process oriented. There are processes at each layer". This is obvious in the BPM layer. Michael goes on to discuss how ESB processes are single-burst stateless processes and how orchestration processes are both stateless and stateful. So why is this important? Michael states that "it is easier for developers to model a service as a process than to code it explicitly in a third-generation language". Another important point is that since SOA is a business driven architecture and business analysts and business people are more comfortable looking at use cases and process models, technicians need to start thinking in these same terms. After all, "Bad processes mean bad SOA" as Michael concludes.

The remainder of the book dives into topics such as design decisions on whether a process belongs in the BPM layer or within the lower SOA layers, modeling using BPMN & BPEL, design decisions for both short & long-running processes, using the "Flat-Form" method of modeling processes, dealing with dynamic processes, Simulating SOA, and concluding with measuring SOA complexity.

Some key points worthy of mentioning:

• A very worthy discussion of simulating SOA performance takes place in chapter 8. Michael recommends that simulation occurs before a line of code is written. When this does not take place it raises the risk of performance surprises in the production environment which may or may not occur right away. When these issues occur in production, resolving it becomes extremely expensive and can have catastrophic impacts.
  

• The Flat-Form method of modeling processes is a must read. I won't spill the beans here but the methods intent is to flatten the process models to improve maintainability and simplicity. Great stuff!

Overall, I really enjoyed the book. I have read a ton of books on SOA and most of them are high level discussions on what SOA is and how to get started. This book picks up after those discussions and is a great tool for architects and developers who have to actually build and deliver SOA. I highly recommend it! I also recommend that your testing lead reads the book as well. If you don't have a tester who understands the content of the book, you better get one!

Next up is my colleague Todd Biske's SOA Governance book which I will finish reading this weekend!

I have discussed the SOA Evangelist, the Architects, and the Developers. Today I will discuss the role of the Testers and the characteristics required to contribute to a successful SOA implementation.

One of the most important roles and one that I probably should have included in the Architects post is the Testing Architect. As I have written on CIO.com in my article called Six Questions to Consider Before Building a SOA Testing Team, SOA testing requires a much deeper knowledge of technical skills, including development skills. It might be unrealistic to expect your entire testing team to possess the desired technical skills required to successfully test SOA, but your test architect and your leads should be able to understand concepts like statefullness, distributed computing, and data services, to be able to properly validate the underlying architecture. They also need to be able to take developer test harnesses and update them with their own test scripts.

A successful SOA testing strategy starts with the test architect. This person must have a very in depth knowledge of SOA and should work closely with the EA team. I actually recommend that this person is a member of the EA team, but every business and culture is different. The goal of the test architect should be to set up a framework and a core group of policies and procedures (part of IT Governance) so that the rest of the test team has the tools and the guidance to successfully test SOA. Without an established testing architecture, the company will have to rely heavily on expert knowledge from the entire testing team. I have seen three scenarios through my personal experiences and through my research.


Scenario 1: Underestimating SOA
The first scenario is out right failure caused by not having the tools and knowledge required. This is caused by a company not realizing that their current methodology and internal personnel are not well equipped for testing SOA. These companies do not invest enough in tools, training, and governance and usually can only test the presentation layer and possibly the interfaces. By not understanding the concepts of SOA, they are unable to validate the architecture which leads to poor performing and fragile services.

Scenario 2: Paying through the nose
The second scenario I have seen is relying too heavily on "expert" consulting firms for testing. In this scenario the company bets the farm on an experienced SOA consulting firm and pay rates that far exceed $100/hr. This model cannot be sustained for any length of time unless the company is willing to burn huge amounts of capital (which is not a popular thing to do these days).

Scenario 3: Good balance of internal/external expertise
A more desirable scenario is to train or hire a SOA testing architect, build a solid testing platform tailored for the needs of the organization, and govern the testing process while training the other members of the team. Companies should hire one or more experienced SOA tester, find an experienced consultant or two, or train an experienced and credible internal candidate to take the lead for creating the testing architecture. At the same time the testing experts are charged with transferring knowledge over to the rest of the internal team members. This is critical because a highly experienced SOA tester is in great demand and is a flight risk since they are a rare breed. It is critical to grow the knowledge base internally.

Testing needs
The needs can be broken down into these categories: People, Tools, Governance. So what are the characteristics of a successful SOA tester. The answer is dependent on the architecture that is implemented, which is related to the tools and policies that are put in place. Below is a diagram I often use to discuss the typical layers of an architecture.

From SOA Slides

As I mentioned in the previous discussion about the developers, I see the need and desire to specialize within the layers. The same holds true for testers. Work within the layers happens simultaneously in development. I recommend an iterative development and testing approach which means there should be testers working within the layers simultaneously as well.

Here is what I would strive to put in place, keeping in mind that these are roles and some people may fill multiple roles:

SOA Test Architect
Courageous leader with extensive working knowledge of SOA, distributed computing, integration testing experience, coding/scripting experience, and understands the business. It is likely that you may have to go outside to hire this person or bring in a consultant to assist your top level tester.

SOA testing leads
This person or persons must understand all layers of the architecture (let's not forget security either) and should be able to design test plans that validate both the architecture and the governance model. They should understand how to perform black, white, and gray box tests. Testing abstracted services requires extensive testing in the areas of security, performance, and regression. Throw in the versioning capabilities of services and the fact that service consumers can use services in ways that were not anticipated and the permutations of test cases start skyrocketing. The test leads need to practice risk based testing and balance risks, timelines, and costs. There is just so much more at stake here than in the traditional n-tier architectures.

Business process testers
The business processes should be modeled within some tool and will likely call one or many services. The process flow requires a series of decision points based on variables and constants and can trigger events such as notifications, alerts, other processes, error handling routines, services, and a variety of other possibilities. The testers need to validate the business process as a stand alone entity. For example, if the business process is "validate credit card", the tester needs to ensure that this process handles the inputs correctly, properly runs the validation process, and generates the appropriate output. At this point, the tester need not be concerned with any other processes or services. These testers must work closely with the business and/or business analysts and do not need the breadth of technical knowledge that the leads and architects must have (although it would help). They should be approaching the testing from a business standpoint.

Integration testers
These testers must be much more technical and understand how to work with XML, SOAP, WSDLs, networking & telecommunication concepts, statefullness, and various platforms and technologies (Java vs .Net, Windows vs Unix/Linux vs. mainframe, etc.).

User Interface testers
The company most likely already has an abundance of people who can test the UI. If your company is leveraging mashups, wireless devices, or consumer facing UIs, the complexity of the testing will be greatly increased. These testers may be need to become familiar with AJAX, RIA, portal technology, RSS, and a variety of social software.

Data services testers
These testers must understand concepts of data modeling, database CRUD operations, transformations, security and roles, authentication, and much more. Everything starts with the data and if errors are introduced in this layer, everything else is doomed to fail. You must have a very strong testing lead working in the data services layer since data is the foundation of any successful implementation.

Other areas of focus
The name of the game is speed to market and test automation is a critical component for making that a reality. Performance testing is extremely critical and organizations should practice simulations to try to anticipate future performance of all services. Validating the security model and the governance model should also be part of the overall test strategy. Whoever is responsible for designing the security test plan should read (and fully understand) this book.

Closing comments
I am by no means a testing expert (but I did stay at a Holiday Inn Express last night). I do read a number of testing blogs listed below:

• Randy Rice's Software Testing & Quality Blog
• Frank Cohen's blog
• The ITKO Lisa Soapbox: SOA testing, validation & virtualization
• SOA Testing
• Mike Kelly's testing blog

Make sure your organization funds the necessary training and tools for testing. From my own personal lessons learned, make sure you invest as much effort in testing and security up front as you do in architecture and development. On my project a few years ago, I wore my developer hat too much in the research phase and did not properly budget for what was necessary for testing. Do not make this same mistake. As hard as it is to sell the business on SOA, it is much harder to go back for more money, especially before any business value is realized!

For those of you who have been reading my blog for the last two years, you might know that after 13 years at my previous job I left the company this summer to pursue multiple opportunities that were available to me. I have been doing some consulting and freelance writing in the mean time but have finally found my new gig. I will be the CTO/Chief Architect for a startup (more details forthcoming in the future) and will have the opportunity to work on some of the newer technology initiatives. So here are some of the future blog topics that I will start covering in 2009 once I get rolling:

1. SOA - can't seem to let it go! As I wrote in a post at CIO.com, I believe SOA is not just for legacy systems and can be the foundation that startups can leverage as a competitive advantage (see the reasons why)
2. Cloud Computing - Startups typically have low budgets and leveraging platform (PaaS) and/or Infrastructure as a Service (IaaS) can be a great way to both minimize costs and reduce time to market. As I go through the requirements analysis, risk analysis, vendor analysis, proof of concepts, prototypes, and deal with issues such as stability and privacy, I will share my lessons learned here.
3. Open Source - We will likely leverage many open source solutions and I will discuss those experiences and decision points here.
4. Social Software - The company is based in the North East and I live in Florida. It is highly possible that the team I build will be dispersed all over the country and possibly even the world. There will be great lessons learned discussions as well as evaluations of tools to help enable working remotely (virtual whiteboards, live meetings, SaaS solutions for defect tracking, etc.).
5. Agile - One of our goals is to deliver quickly and at low cost. This involves a lot of the above mentioned topics and will also lead us into the world of Agile Development. I will discuss our challenges and lessons learned in this area as well.
6. C-Level IT topics - In my new role I will be working side by side with other C-Level people within the company as well as with C-Level people of partner and customer companies. I will have to hit the road and sell and/or promote our products/services and will try to shed some light on some of the interesting topics I come across.
7. Misc - Other topics that might be worthy of discussing (examples: impacts of financial crisis, VC funding, selling technology to business people and customers, etc.)

In addition, I still do some freelance writing and blogging from time to time. I have a series of discussions coming up on enterprise mashups and will blog about it in the next week or two. I am attending and speaking at the EDM Summit in Orlando next week and will definitely be sharing my presentation on Business Intelligence as a Service as well as covering topics like business rules management, data warehousing, IT governance, and others. I also have two books from Packt Publishing to review:

• SOA Governance by Todd Biske
• SOA Cookbook by Michael Havey

Once I finish reading these I will post a review on my blog. I am half way through Todd's book so far and really like it.

And finally, I am open to covering any topic that any of my readers would like me to discuss whether it is on this blog, over the phone, or in person. Whenever I travel I send a Tweet on Twitter to let people know where I can be found. I will be in Pittsburgh from Saturday 10/25 through Monday 10/27 if anybody lives there and would like to meet. Don't bug me from 4:15-7:15pm on Sunday because I'll be at Heinz Field pulling for my Giants against a tough Steeler team. The rest of next week I am at the EDM Summit in Orlando.

I look forward to sharing these topics with you all. Over the next two months my focus will be on the business plan and creating a team. We officially launch the company in the December-January time frame. At that point expect to see more discussions on the topics I mentioned above.

I have discussed the role of the SOA Evangelist and the importance of the architects. Today I will discuss the different developer roles and the characteristics that make a successful SOA developer.

In a traditional 3-tier architecture it was common that there was a presentation layer, a middle tier or application layer, and a data layer. In some cases, a single developer role was responsible for all three layers. In larger companies, there may have been specialized roles such as a UI developer, an application developer, and a database developer. In an SOA, the concept of an application is no longer relevant except from the standpoint of integrating to existing applications. With SOA, we should be building business services that are application independent. The following chart is one I have used in previous posts which shows a typical breakdown of some of the development roles required for SOA.

From SOA Slides

So let's talk about business services. A business service is the compilation of all of the work done by the collection of developers within each layer. For example, let's discuss a "Shopping Cart" business service like the one we use on Amazon.com. It is most likely made up of services and/or components that live within each of the various layers of the architecture. The presentation layer obviously contains the physical implementation which the user sees and interacts within the browser. The business process layer contains the logical flow of steps that walk the user through the checkout process from start to finish. The business rule layer contains rules about tax codes, discounts, memberships, etc. and the underlying data elements and structures are handled in the data layer. In many instances, companies have multiple data structures that serve similar functions due to mergers, acquisitions, years of legacy systems, 3rd party application purchases, and many other reasons. To abstract these different data structures and present a common data interface that hides the complexity of the physical implementation of the data, the data services layer exists (think master data management).

So to develop this shopping cart business service, all of the people working within the different layers of the architecture must collaborate to deliver the service in a way that it both meets the business requirements and the technical requirements as defined by the SOA Governance model that the company has adopted. Examples of the technical requirements might be...

• Adheres to WS-* security standards
• Data encryption policies
• Platform neutral implementation
• Meets specific performance requirements

Why do I bring all of this up? Because developers that will succeed developing in a service-oriented architecture need to have the following characteristics:

• Flexible, open to change
• Collaborative
• Able to work in a setting with peers reviewing their work
• Able to see the big picture
  
• Not married to a certain technology
• Able to withstand constructive criticism
• Innovative

Developers who are protective of their own work or of their technology of choice will likely struggle working on SOA. One of the goals of SOA is to build platform neutral software that is highly flexible, maintainable, and loosely coupled. To build software like this we must shift away from software developing and move to software engineering. In simple terms, we must move from drag and dropping to planning and modeling. We must embrace collaboration, peer reviews, and governance. If your developers don't like these requirements, they either need to change or leave. Otherwise they will be a cancer and will continously feed the forces of resistance.

Ok, off my soap box now. So let's discuss the roles. But before we do let me note that we are talking about roles and not individuals. In smaller companies, a developer may perform multiple roles. In larger companies we may actually see very specialized developers living within a single layer of the architecture. One last disclaimer: I am assuming that an architecture team exists and some form of standards and governance is in place within each layer.

UI developers
If your company can afford to specialize, this is the perfect layer for it. Developers in this layer do not necessarily have to be extremely technical. It is more important that they understand usability, UI standards, and web interface best practices. These people should be comfortable working in prototype mode where they can start with mockups and work closely with the business or business analyst to reiterate through the various visuals until an agreed upon format is approved. These developers must be able to talk to the business in business terms and understand how typical business users interact with web technology.

Business Process developers
There are two distinct roles in this business process layer. One role deals with modeling business processes, the other role deals with integrating business processes with the underlying services and systems. In some companies this role may be served by one person but more likely it will be two because of the difference in the skills required. The business process modeler may not even be an IT person. Some companies have a department that exists within the business that focuses on business process improvement and business process automation. This is the norm for companies that practice Six Sigma or Total Quality Management (TQM).

The business process integrator is a technical role which requires expert experience working with Web services, REST, JMS queues or several other technical areas of expertise. The integrator is the person who connects business processes to the backend technologies which controls the overall flow of the business services and overall composite business application, often coined orchestration.

Business Rules developer
This one is a little fuzzier. Not all architectures have a distinct business rule layer. In some instances, the business rules are controlled in the data layer. For companies who have very dynamic business rules, especially rules that are customer centric and could be updated by end users and even customers, it makes a great deal of sense to abstract the business rules. If a company has a business rule layer and implemented a tool to manage business rules, it is highly likely that you will need technicians who govern this layer much like DBAs govern the database layer. In some case this might be an additional role for a DBA but it does not have to be. Whoever it is they must understand the concepts of abstraction and be looking for ways to empower the end user to react quicker to changes in the business. For example, let's say that a loan approval process requires state specific business rules about what percentage of capital is required from a loan applicant up front before the loan application can be expected. The frequency which this value changes varies by state and must be updated as soon as possible. The best scenario is to take IT out of the process and enable certain users (or systems) with the appropriate authority to update the values as necessary. Whoever is responsible for the business rules must be able to work with the business and/or business analysts to understand the frequency of change, the rights and permissions, and the impacts of the various business rules. There is an amount of overhead associated with creating and managing rules and the person in charge must understand the trade offs.

Data Services developer
Maybe a better name for this person is an information architect. The person in charge of this function is responsible for abstracting the underlying data layer and exposing it the other layers of the architecture and even externally to other systems. For example, let's say that our shopping cart business service allows multiple forms of payment (American Express, Visa, and Pay Pal). In addition, the different products purchased (books, DVDs, clothing, etc.) are managed from different inventory systems. To hide that complexity and to allow us to add additional payment services and inventories with ease, we leverage data services to present the shopping cart service with a logical view of the data. In other words, we create a standard payment and inventory message that the shopping cart communicates with. As long as the shopping cart communicates with these standard messages, the underlying physical implementation of the different payment and inventory services are irrelevant. The shopping cart service simply communicates these messages in the standard format it knows and the translation from the standard message to the physical layout of the receiving systems or services is performed in the data services layer.

From SOA Slides

(This slide is from BEA)

Developers or architects within this layer must have exceptional technical knowledge in the area of data modeling and database design. If the company has a tool to manage this layer (which is highly recommended) then an administrator is also needed.

Database developers
This data layer is typically an area that already exists today within each enterprise. This is where the DBAs live. With SOA, the DBAs must work extremely close with the developers within the other layers of the architecture. They must understand the performance and security requirements of each layer and ensure that the underlying data model meets the needs. Since legacy integration is common in many SOA implementations, DBAs are often called upon to create views or structures or even establish new ETL processes to provide a common view of data to expose to the other layers of the architecture.

Security developers
The security experts may not actually do the development but there must be a person or group of people who understand the new security challenges that SOA introduces. SOA can introduce the following new threats:

• Expose components of legacy systems that were never designed to live outside the firewall
• Require trusts between multiple internal/external systems without additional sign-ons
• Send a single message to multiple partners each with their own distinct security requirements
• Expose credit card and other privacy related data out on the web

From SOA Slides

(This slide is borrowed from the following presentation from Mamoon Yunus of Forum Systems)

Todays n-tier security models are not enough when dealing with B2B type SOA implementations. The developers in this area must have a deep understanding of communication protocols, security best practices, web architecture, regulation (ie. HIPAA, SOX, PCI) and WS-* or other standards.

Summary
As you can see there are many distinct developer skill sets required to implement SOA properly. Trying to find a person that can master each layer is not realistic. If you have this person, it is likely that he or she is on your architecture team. The beauty of this architecture is the ability to divide and conquer the problem within each layer. A single business service can be worked on by numerous people within each layer. It requires solid governance, strong collaboration skills, and teamwork to work this way which is why it is critical that the right team of people is assembled to tackle SOA. My next post will discuss the testers and their relationship with the development team.

In part 1, I discussed the importance of the SOA Evangelist. I also talked about the shift from software development to software engineering. This shift has made the role of the architect critical for the success of any SOA initiative. First, let us talk about the various architect roles required to successfully design an SOA.

Chief Architect - This person, possibly your SOA Evangelist, should have strong technical skills, sound business knowledge, and great leadership skills. Not only should this person understand the ins and outs of SOA, but he/she should be able to explain the value of SOA to the business in business terms, to the CIO in high level technology and business terms, and to the technicians in detailed terms. Depending on the size of the company and the SOA initiative, this person may or may not actively participate in the design. Regardless, this person should be knowledgeable enough to participate in design sessions when called upon. From a leadership perspective, this person is likely the change agent who is the driving force behind establishing and implementing governance, shifting the IT mindset from programming to engineering, establishing the SOA roadmap, and other culture changing elements.

Enterprise Architect - In smaller or midsize companies, the chief architect and the enterprise architect may be one in the same. In bigger companies, there may be more then one EA. The EA has broad domain and business knowledge and works across organizational boundaries to ensure that the architecture meets both the business and IT requirements. Wikipedia says it best when it mentions....

The role of the Enterprise Architect is to take this knowledge and ensure that the business and IT are in alignment. The enterprise architect links the business mission, strategy, and processes of an organization to its IT strategy, and documents this using multiple architectural models or views that show how the current and future needs of an organization will be met in an efficient, sustainable, agile, and adaptable manner.

Domain Architect - The domain architects specialize in specific areas of technology. They are the experts of their domain. Here are a few examples of domains that require specialization:

• Application
• Information
• Security
• Infrastructure
• Business Processes
• Network
• Integration

Once again, the size of the company often dictates how many of these roles exist as a stand alone job function or if they are rolled up into a broader architect role. For example, smaller companies may combine application, information, and integration into one role and infrastructure and network into another role. The key for me is that these roles need to be accounted for regardless if its by one or many people. Each role is critical in successfully architecting a true SOA.

Solution Architect - The solutions architect has hands on experience with specific technologies and even business applications. You may have an architect who specializes in Java, .Net, backend systems, web applications, financial systems, ecommerce systems, distributed processing, etc. Once again, I am advocating that the role is addressed and whether or not a company has one or many people with this title depends on its size and budget.

The Architecture Team
As I described above, the team should consist of the following roles (not necessarily individuals):

• Chief Architect
• Enterprise Architect
• Domain Architects
• Solutions Architects

The number of people filling these roles vary from company to company. In my previous job, a shop of roughly 200 people, our architecture team consisted of myself as a Chief Architect, an EA, a domain architect, and a solutions architect (even though they all had the simple title of "Architect"). There was an Architect over the infrastructure and network that reported into a different structure and a one person security team. My architect team worked closely with the others but it would have been more effective had we all been on the same team with the same goals and objectives.

I have seen a case study at an enterprise architecture conference a few years back where a global SOA initiative for a fortune 100 company had over 100 architects on the team including numerous EAs and even multiple Chief Architects from different business divisions. There is no one way to slice this pie.

Architect Mindset
You can organize the teams anyway you like but one thing you must have is the proper mindset. The architecture team must be focused first on the business drivers that the SOA initiative has set out to solve. If the team loses sight of these drivers then SOA will become an IT project instead of an important initiative for the entire corporation. You must have the business buy-in throughout the project to reap the true benefits of SOA. Please read 8 Winning Characteristics of Successful SOA Implementations which I wrote for CIO.com that summarizes the critical success factors that wer common among the winners of the SOA Consortium/CIO.com SOA Case Study contest earlier this month.

Second, the team needs to ensure that they are not an Ivory Tower architecture team. SOA is too important for architects to be preaching philosophy from the top of their perches. The architect team must be the change agents required to move the organization away from the traditional silo driven application development approach and into a more collaborative engineering approach that focuses on the long term vision not the short term and short sighted approach that many companies practice today.

Third, this team must have an open mind. They need to evaluate current business processes, current IT practices, and current systems, and provide the necessary change and direction required to move the organization forward towards the vision established by the business and IT and reflected in the SOA roadmap. Without changing the way IT approaches development, it is likely that the team won't be able to differentiate between SOA and web services. Education and evangelism is key to understanding the proper way to architect and govern your SOA.

In part three I will discuss the developer role. In part four I will discuss the testers.