Joe's Thoughts on Software Architecture

The January issue of Xchange Magazine, a telecommunications industry publication, presents a number of articles on cloud computing for the telecommunications industry.  Since no other industry faces as profound transformation from cloud computing the way telecommunications does, this is a extremely relevant topic for 2009 - the fact that they put me on the cover has no bearing on this opinion.  

With the recent innovations in wireless, computer, and web operating platforms combined with the evolution of broadband and wireless networks - not to minimize the fact that these platforms and networks will need to be managed, the options for technical innovation in telecommunications are as wide open as they have ever been.  With all of the possibilities presented to the industry, the only point of clarity in telecommunications is that the convergence of applications on disparate devices combined with services hosted in the cloud hold the future of one of the oldest technology industries. 

The details that are not as clear are things like how the FCC will address pertinent issues like net neutrality - especially the open access provisions, and spectrum allocation from the broadcast networks - the "white space" debate.  The current economic downturn and the amount of capital that has disappeared from the markets will also have an impact as to rate of implementation of these new technologies.

My personal  CaaS experience, as an architect on Avaya's Hosted IP Telephony program, never came to fruition.  But seeing CaaS platforms like IntelePeer's AppworX and service delivery platforms being developed by network equipment providers and network service providers makes me feel good that the vision that I spent a good portion of my career working on realizing will come to reality in a short timeframe.  Hopefully, 2009 will be the year that this paradigm shift gains momentum.

The articles on cloud computing that are in this issue of Xchange

are:

Cloud Computing, Part 1: Clearing the Air

Cloud Computing, Part 2: Gauging the Opportunity

Cloud Computing, Part 3: Deliver 'XaaS' From the Cloud

Cloud Computing, Part 4: IBM Gets Cloudy

This interview from the Internet Telephony Conference has been posted on TMCnet CaaS community site.  In this interview with Charles Studt, VP of Product Management and Marketing from IntelePeer, and me we discuss SaaS/CaaS and Cloud Computing and the platform that IntelePeer is building using Windows Live Services. 

Here is the Link to the video: http://www.tmcnet.com/tmc/videos/default.aspx?vid=609

Travis Brown and Gary Sidhu from Qwest Communications and I have written a whitepaper on the benefits of using the Visual Studio DSL toolkit for a software system that activates IP VPNs for a telecommunications network service provider.  The whitepaper makes use of the TMForum's Shared Information and Data (SID) model and the DSL is based on the RFC2547bis standard. 

This paper is available at this link on MSDN: http://msdn.microsoft.com/en-us/library/dd320274.aspx

Last month I sat on a SaaS panel during the Internet Telephony conference in Los Angeles.  The panel began with opening statements from the speakers, and much to my surprise the first speaker went into a diatribe on the notion of SaaS as a concept and architecture, how SaaS had no meaning, and how anybody who tried to define what SaaS was was fighting a "religious war."  The speaker kept hammering the point that a business shouldn't care about how to deliver products and only care about the product to be delivered.  He seemed to be alluding to the the seminal "IT Doesn't Matter" article by Nicholas G. Carr - an article that I've lectured about at the University of Denver and find to be one of the most misunderstood publications (maybe people should read it twice).

In the weeks since, I have given some thought toward the speaker's comments - the speaker is certainly not alone in his beliefs.  There are different roles in most corporate environments that allow people to focus on specific aspects of delivering a product and everybody doesn't need to understand how a product will be implemented.  That being said, I'm becoming more alarmed at the number of people who are adopting this attitude as the web is becoming the public portal for many businesses, or in the case of many web 2.0 businesses the business itself.

In an article entitled "Why How Matters" in Tuesday's New York Times, Thomas Friedman talks about the financial crisis and how indifference toward how things work helped get us into this mess...he mentions an attitude pervasive within finance companies that "you'll be gone and I'll be gone before the bill comes due."  This hit home with me, since this is effectively the attitude that many have about information technology. 

That being said, without understanding how technology works people can't  assess the total cost of ownership for the lifetime of a software solution, leaving them at a huge financial disadvantage.  

• A majority of the costs associated with  a software system occur after the initial release, yet most business people focus only on the cost of the initial deployment as opposed to caring about the support/maintenance and extendibility of the solution.  It is analogous to only considering a honeymoon without thinking about the marriage - let's face it there are people who you may want to vacation with in Hawaii with but not want to spend the rest of your life with.  Technical decisions must be made with an understanding that you may own the product for longer than you anticipated.
• All products are not created equal and some have additional features and capabilities that may make the product more useful beyond it's initial intent.  An example is business intelligence built into database systems - this can help business forecasting and improve productivity - this is only a concern once the system goes live.  This can be overlooked by people who don't understand the details of modern database technologies.
• Business leaders must also understand the number of successful deployments of a given technology and the number of developers with experience on that technology.  These can also add HUGE costs to the development and maintenance of the solution.

That being said, you may be wondering how I reacted to the other speaker.  I just gave my presentation and basically ignored the comments.  The audience had expectations of the content that was to be presented and even if I was boring them to death about something that (according to the other speaker) they shouldn't care about I committed to give a talk on SaaS architecture and that is what they got.  I wouldn't argue with a nihilist about the meaning of life and didn't argue with someone who vehemently questions the need for technical understanding about software architecture.

There was an interesting article on CNET News on September 12, 2008 describing a forum on cloud computing hosted by Google.  The article provides a series of quotes from members of the panel.

Notable comments from Mike Nelson, a visiting professor at Georgetown University's Center for Communication, Culture, and Technology and a former tech policy adviser under the Clinton administration:

• "Most users understand enough" to feel comfortable with cloud computing, Nelson said, "but they don't understand what can happen to that information. There's a definite need for education in that area."
• politicians needed to learn more about the implications of cloud computing as well
• "The government has an almost unlimited capacity to screw up things," Nelson said. "We've got some huge challenges ahead of us."

Notable comments from Ari Schwartz, vice president and chief operating officer for the Center for Democracy and Technology, said

• there should be enough protections and privacy options for consumers online that "we should get to a point where it doesn't make a difference" how much users understand about the privacy risks of cloud computing
• "Consumers expect their information (on the cloud) to be treated as if it were stored on a home computer," Schwartz said
• once a user moves his data online, he loses the Constitutional rights he would have had over the data on a home computer

I firmly agree in this assessment: consumers and policy makers both need to understand the implications of privacy in the world of cloud computing.  Privacy is a very important matter when it comes to cloud computing, especially in terms of data.  In the course I taught this Spring, I was SHOCKED at how naive the students were about privacy on the Internet and spent a class teaching them about how they lose all privacy once they're on line.

I also think that during this time that the cloud is becoming a dominant computing platform it is extremely important that consumers are aware of the privacy policies of the providers of their cloud services.  Ultimately it is the consumer who needs to understand where their data lives and the implications of that data falling into the wrong hands.  I firmly believe that the companies that implement policies that respect the privacy of their customers will win the largest amount of market share in this emerging platform.

Here is the link to the full article:

http://news.cnet.com/8301-13578_3-10040709-38.html?tag=newsEditorsPicksArea.0

SOA Telecom Architect, an on-line publication focused on service oriented telecommunications software, published this press release on the panel that I will be part of discussing SaaS (and CaaS).  Also participating in this panel are representatives from Jamcracker and IntelePeer. 

For those less familiar with IntelePeer, this week they released their AppworX platform, which is an open CaaS platform that seamlessly delivers enhanced voice and multimedia features from within any Web or IP-based application to any phone or network-connected device.  This platform is accessible through REST based APIs that allow easy integration into software systems and business processes.

Here is the link to the SaaS overview press release: http://soatelecomarchitect.com/2008/09/09/jamcracker-to-present-saas-overview-at-2008-internet-telephony-conference.aspx

I will be on a SaaS panel at the Internet Telephony Conference and Expo in Los Angeles on 9/17/2008 (details below).  If you're attending the conference and interested in chatting about SaaS/CaaS/S+S/Design Patterns/.NET/Baseball/Bicycling/Jazz/or the upcoming ski season send me an e-mail and we can set a time to get together.

Software-As-A-Service: The Basics
(SAAS-01)

Wednesday - 09/17/08,  9:00-9:45am

You may remember the term “Application Service Provider” or “ASP.” You may frequently hear the terms “hosted” or “on-demand” thrown around. You may be dizzy with confusion as to what all these terms mean, how they are similar and how they are different. You’ve heard SaaS can save you money, but how? Is your organization suited for software-as-a-service delivery? If it can save you money, where, exactly, do those savings occur? Where does the return on investment lie? Did you know that SaaS solutions can be accounted for in a completely different way (as an operating expense rather than a capital expenditure)? What are the implications for your business? What are the benefits? Where do the pitfalls lie? After this session, you’ll be a pro at sorting out all the terms for this model of business, and you’ll know if and how it’s right for your company.       

My colleague Michael Scherotter, a User Experience aficionado, will be conducting a Silverlight and WPF workshop in NYC on 9/3/2008.  Foe more details on this workshop, please go to Michael's blog at: http://blogs.msdn.com/synergist/archive/2008/08/27/silverlight-and-wpf-workshop-in-nyc-9-3-2008.aspx

I will be at NXTComm next week talking about Services Syndication for Communications as a Service (CaaS) solutions.  Services Syndication allows for the aggregation of CaaS services into a cohesive product offering and addresses many of the management aspects of a CaaS environment like provisioning and billing.  Please stop by the Microsoft booth to learn about this topic and discuss it with me.

My colleague Michael Scherotter and I had a couple of conversations about CaaS on Michael's Communicating show on MSDN's Channel 9.

The first show contains an overview of CaaS.  This show talks about: the evolution in telecommunications equipment from monolithic hardware and software solutions to applications implementing a Service Oriented Architecture (SOA) on commodity hardware; trends in networking that support CaaS; and the other tenets of CaaS, like multi-tenant software.

http://channel9.msdn.com/shows/Communicating/Communications-as-a-Service-CaaS/

The second show covers the conceptual architecture of CaaS - which is a layered architecture that create a strict separation of concerns between parts of the solution.  This seperation of concerns supports a flexible architecture that is essential to the successful deployment of a CaaS application. 

http://channel9.msdn.com/shows/Communicating/CaaS-Conceptual-Architecture/

I plan on increasing my writing and creating videos on CaaS.  Future topics will include: CaaS and Services Syndication; the infrastructure required to deliver CaaS applications; lessons learned from a CaaS project; and Managing a CaaS environment.

It's been over a week since The Architecture Journal published it's latest issue and my article "We Don't Need No Architects."  The intent of this article was to present some of the common perceptions of architects in the IT community and look at the skills possessed by effective architects.

As could be assumed in any article about architects in IT, the feedback on this article has conjured up some raw emotions - which is honestly appreciate.  I enjoy candid feedback and appreciate the respectful, and sometimes humorous opinions.

The first blog written on the article, even before I knew the journal was posted, was We Don't Need No Architects--Really!.  This rebuttal to my article helps illustrate the raw emotions conjured up by the title architect.  The blog expressed disappointed my article didn't renounce the entire profession of architecture in IT and felt that the skill set that I presented was more applicable to developers.  The blog concludes with an explanation on how the title architect should be eliminated from IT in order to remove the confusion caused by the title.

Other feedback I have received :

The article you wrote on the Architect Journal was very helpful and made me feel proud about my job.  An Architect is assumed to be a a) Another name for sr. developer b) Technical guru who is supposed to know everything c) Or does nothing other than throw in Jargons.  You article threw light into it. Thanks!.

and

We fully agree with your definition of the architect where we came to as well with exception of the patterns part (we do apply this, but it is so obvious one tends to forget to put this in the job description). - I responded to this reader saying that his organization is fortunate to have so many resources versed in patterns.

Finally, my favorite feedback was from a blog that simply describes architects as "over forty and over confident."

Thanks for the feedback!  Select this Link to join a discussion on the role of an archtiect.

The latest issue of The Architecture Journal from Microsoft has been published and my latest article, "We Don't Need No Architects!" has been included in this issue.  My article examines the profession of architecture in the field of information technology by looking at the perception of architects within the industry as well as the skills possessed by effective architects. 

The title of the article stems from the perception of some in the industry, that the profession of IT architecture is without merit - a perception that I once held some time ago.  The article examines why these perceptions exist, giving examples of bad practices among those of us in the profession (including some gaffes of my own).  Ultimately, as stated in the second paragraph of the summary, the article presents a defense of the profession.

Another article that is in this months Architecture Journal is by a colleague of mine, Joe Shirey.  His article "The Softer Side of an Architect" is an excellent article that focuses on the interpersonal skills possessed by successful architects.  Our articles are very complimentary, one focusing on the hard skills and one on the soft skills of successful architects.  A couple of interesting coincidences are that Joe and I both work from the same Microsoft location in Denver, neither of us knew that the other was working on an article for this journal, and our articles cover the two sides of the same topic.

Happy reading.  Feel free to send feedback.

Communications as a Service (CaaS) is an architecture for communications applications.  CaaS extends the principles of a Software as a Service (SaaS) architecture by adding a control layer based on the Session Initiation Protocol (SIP),  The ability to leverage an application layer signaling protocol in a hosted environment has the potential to radically change the software industry.

The link below is my article on CaaS.  This article begins with a definition of CaaS.  The article then goes on to describe the fundamentals of the SIP protocol and the IP Multimedia Subsystem (IMS), which defines an infrastructure for Fixed/Mobile convergence.  The article concludes with a reference architecture for a CaaS solution.  Subsequent articles will dive deeper into different parts of the architecture.  

 http://msdn2.microsoft.com/en-us/library/bb896003.aspx

People may wonder why I would call the Session Initiation Protocol (SIP) “The Next Frontier.”  “The Next Frontier,” conjures up images of spaceships, planets and intergalactic battles.  Certainly a communications protocol can’t be that exciting.   But, in the spirit of 2007, a year when a telephone can generate enough excitement to get people camping out at strip malls, “The Next Frontier” may not be too much of a stretch to describe a communications protocol.

Why is SIP important?  SIP lowers the barriers of entry for developers of communications applications.  Signaling protocols traditionally existed at the physical layer, SIP exists at the application layer.  That translates into the ability to develop a SIP based application and plug it into a SIP infrastructure without concern to the underlying transport, for example wireless or wire-line.  The SIP infrastructure gives the ability to create event driven applications that contact the end user on the device of their preference.  In other words, applications using SIP can communicate with an end-user wherever they are, on whatever device they specify, using multiple forms of media (video, voice, and data).  

SIP Messaging

SIP is an application level protocol that creates a media session between two or more user agents (UA) – SIP enabled endpoints.  SIP is a “rendezvous” protocol, which extends it past signaling and allows a UA to communicate with other UAs in ways that traditional telephony cannot.  SIP allows a UA to request information about or provide information to another UA.  A UA may range from a SIP phone to a multi-media device, like a laptop or a smart phone.

A SIP Request is used to establish a dialog between two UAs.  A SIP Response is a three digit numerical code, with the first digit indicating the class of the response (for example, a success response would be a 2xx response code).  A SIP Transaction is a SIP request and the final SIP response to that request.

SIP Messages are similar to an e-mail message with a request Uniform Resource Indicator (URI) as the destination and the body in Multipurpose Internet Mail Extensions (MIME).  The header of a SIP message contains information used by the SIP application.  The SIP message body supports multiple content types, from plain text and HTML to presence and conferencing state information.  To create a dialog, SIP uses the Session Description Protocol (SDP), with one party making an SDP request and the other replying with a SDP answer.

SIP Infrastructure

SIP contains an infrastructure far larger than the UAs that are establishing the session.  Devices in this infrastructure may include: the SIP Proxy Server; SIP Redirect Server; and SIP Registrar Servers.  It is important to note that all of these devices are logical, meaning that they do not need to be physically deployed as separate processing elements.

The SIP Proxy Server receives a SIP request and forwards the request.  A common usage for the SIP proxy server would be for Network Address Translation (NAT) or firewall access control.  The SIP Redirect Server receives a SIP request and performs a query, returning the results to the requesting UA.  The SIP Registrar Server allows a user to associate a UA with their identity; this is a URI to URI mapping that will be discussed in greater detail in a future posting.

Looking ahead

The purpose of this posting was to get the reader familiarized with the most basic concepts in SIP.  Postings in the near future will include: SIP Call Flow; SIP Events; Presence and Network Concerns.