Guest

Age of Collaboration E-Summit

2010-03-12T03:27:48Z

Miss the E-Summit? Want to watch it again?

View Now

View the presentation decks

W H Inmon, Collaboration: Integrating the Work Product
Glenn Engrstrand, Choosing a Software Architecture for ECM
Joe Moran, A Framework for Deploying Collaboration Solutions

Atlanta 2010 ITARC Presentations

2010-03-09T16:56:02Z

A Turning Point for the Government Cloud

2010-03-08T16:40:56Z

A Turning Point for the Government Cloud

Los Angeles is moving to the cloud, according to Public CIO Magazine March 2010, and “they are the first government of its scale to chose Gmail for the enterprise.”

http://usercentricea.blogspot.com/2010/03/turning-point-for-government-cloud.html

Interesting details about the Google SLAs

Review - Real Enterprise Architecture

2010-03-07T22:25:37Z

This book really is about Enterprise Architecture with the emphasis on the enterprise and not the IT architecture. Written by a frustrated practitioner it offers a cohesive while perhaps not as comprehensive as one might like methodology in a very compact 130 + pages including glossary.

The book starts with devastatingly simple proposition that "Enterprise-architecture is the integration of everything the enterprise is and does." It works for me. The first chapter establishes the methods framework a twenty five cell structure that maps Purpose, People, Preparation, Process and Performance drawn from a project management methodology against five "sideways views". These are Efficient, Reliable, Elegant, Appropriate and Integrated. While I kind of get the 5 Ps I kind of missed the "sideways views". I mean Elegant?

The lack of a foundational theory and the immediate progression to a framework is a little alarming particularly when the rest of the book is then dedicated to filling out the framework. Twenty five cells in about 120 pages (less than five pages a cell) with I must say a reasonable amount of white space at the end of many of the sections. Not surprisingly, there is not much meat to the tools and techniques used to fill out the cells.

Given its size this volume was never going to be much more than a set of architect's notes. But putting that aside and being impressed with it not giving into the temptation of becoming an IT architecture book, I have to be positive about this book. Small, concise and perhaps a little overawed by the concept of recursion this book tackles EA without falling for the IT trap.

This is a book as it says itself for chief officers, strategists and programme managers and I agree with that. This is not the book to start your collection with and probably isn't that much use to the average IT focused corporate architect. And frankly it's a bit pricey for what it is. But, is it worth a slot in your EA library? I'd have to give it a reserved yes. Not wishing to damn it with faint praise, it is what it is.

Graves, Tom (2008), Real Enterprise Architecture, Tetradian Books, Colchester

ISBN 978-1-906681-00-5

Review - Enterprise Architecture Models and Analysis for IS Decision Making

2010-03-07T22:19:00Z

This is an interesting book. In a curious way it is almost devoid of an underlying theory, something I've criticized many methods and books for and yet it maintains a cohesion that is difficult to fault. This book is about models, decision and analysis techniques and that makes it quite a rare and useful volume. I am frequently dismayed by the poor analytical skills of architects that I encounter day to day. This book has the analysis process and its management as its central theme and manages to do it without becoming overly academic which is a bit of a triumph.

Think EA meets operations research and you'll start to get a feel for a book dedicated to rational (no not the IBM brand) enterprise information systems management. This is EA as decision support for the CIO. It discusses strategic issues like goal setting and decision alternatives and domain definition. It then takes these goals and breaks them down into properties and provides techniques for collecting evidence; a practice that isn't as well developed as one would expect in many organizations.

The authors support this approach with a huge number of simple, but thought provoking models just the kind of thing you need to get you working on your problems. My favorite is the credibility of evidence model. There's a section on intuitive EA assessment in which they manage to give the process a lot more structure and logic than the usual rubbish that passes for intuitive analysis. And the section on organizing for EA actually has more content than is apparent on first inspection. But you'll have to work your way through the models. Based on COBIT the EA as a process approach reminds me a lot of Spewak and Hill with the same directness and perhaps a similar failing to grapple with social realities.

The book only credits two authors on the cover however I counted about adozen contributors. The writting is clear concise if somewhat bland typical "Euro Architecture" style, but at 300 pages not too hard a read. This is not the book to base your practice on, it's not strong on governance or business integration. However, it is one of the best technique books you'll find. This is the sort of book that you'll reference more than read. Not a book for beginners or managers but obviously worth its place on your bookshelf.

Johnson, Pontus and Ekstedt Mathias (2007), Enterprise Architecture, Studentlitteratur AB, Lund, Sweden

ISBN 978-91-44-02752-4

Article: SOA and integration in the cloud bring agility and value down to earth

2010-03-03T04:15:31Z

An interesting article about SOA and Integration in the Cloud bring agility and value down to earth.

Read article here

Whitepaper: Examining the Business Value of SaaS Integration

2010-03-03T04:11:23Z

This whitepaper will examine how IBM and Hubspan have combined to create a powerful new cloud based Software as a Service (SaaS) integration solution, called WebSpan, to address today's integration challenges so companies of all sizes can achieve their business objectives. Download Now

Webinar - SOA Core Services

2010-02-26T02:19:07Z

SOA - Core Service
Thu, Feb 25, 2010

SOA is being the key architecture paradigm considered for implementing enterprise wide integration solutions, there is a strong demand from the customers to build core services that would lay the foundation for the business services hosting. I would like present the importance of core services areas, blue print and its value proposition and customer use case scenarios for some of the core services.

Ramesh Babu Palani is a SOA solution architect / application architect in Cognizant technology solutions where he plays multiple roles in the SOA projects across different domains that include BFS, Healthcare and Life science. He works with customer architecture team very closely to solve their technology pain points by providing SOA adopted practical solutions. He has been working on J2EE technology, SOA products from IBM, Oracle and TIBCO and business activity monitoring domain. He has conducted boot camps in IBM SOA technologies and TOGAF methodology for cognizant colleagues. He holds TOGAF, WebSphere Application Server SME, WebSphere Process Server, ebusiness solution designer and J2EE architect certifications. He is active member of WebSphere User Group, TOGAF forums and Enterprise Architects community.

Download WMV

Download PDF

Model Oriented Architect Webinar Software Architecture using Model-Based Approaches

2010-02-23T18:51:36Z

The architecture of a software system defines its primary structural and behavioral organization. A well designed and clearly documented architecture is a crucial pre-requisite for the successful implementation of a software system as well as for its subsequent evolution. In this talk, we examine how the new generation of model-based software engineering (MBSE) methods and technologies can be exploited to facilitate the specification and enforcement of software architectures. At the core of MBSE is the use of higher levels of abstraction and greater use of automation compared to more traditional development approaches.

Bran Selic is currently President and Founder of Malina Software Corp., and Director of Advanced Technology at Zeligsoft Limited. In 2007, Bran retired from IBM Canada, where he was an IBM Distinguished Engineer responsible for the strategic direction of IBM's software development tools. In addition, Bran is an adjunct professor of computer science at both the University of Toronto and at Carleton University in Canada. He has over 35 years of practical industrial experience in designing and implementing large-scale software systems and has pioneered the application of model-based methods in real-time and embedded applications. In the past decade, Bran has led several international standards efforts related to modeling technologies, including the widely used UML 2 modeling language standard. A frequent invited and keynote speaker at various technical events, he is on the editorial board of two major scientific journals and has been the general and technical program chair of a number of technical conferences.

View Now

Thoughts on the Robbins v. Lower Marion School District - Student Webcam Remote Activation

2010-02-23T16:36:37Z

Yesterday, I spent a good deal of the day reading and rereading the class action suit filed by the Robbins family against the Lower Marion School District. The suit alleges that the school invaded the privacy of Mr Robbins (who is 15) and other students of the school district. The schools had provided Mr Robbins and other students with laptops as a part of a program to bring e-learning opportunities to the student body. The laptops were installed with a webcam and can be remotely administered to take snapshots of whatever is in front of the camera. The system was installed to help track missing or stolen laptops but the case alleges that the schools used it for much more.

I believe this case represents a very significant moment for IT architects and technologists in general. The issues at stake are tremendously important and include the privacy and safety of minors, the potential for the abuse of privacy by government, security, as well as government IT policy which could impact millions if not billions of dollars worth of spend. There are so many elements to discuss that it would be difficult even to list them in a single post.

Let's start with a simple but interesting oversight on the part of the plaintiffs. They named 3 groups in the case; a) the school, b) the district and c) the superindendent of the school district. Many of you may not be aware but for some time I have been predicting that IT would begin being named in these types of cases. They did not do so in this particular case but other cases I have seen are leading us there. Here is a question, are any of the named individuals qualified to understand the privacy implications of a complex technology system? Even if your answer is yes, aren't the contractors and IT staff involved equally responsible and much more qualified for identifying and escalating such potential issues? If that is so, what is our (IT architects and IT staff) liability or culpability in these claims?

IASA will be following and pursuing the stakeholders in this case. In addition I will be forming a small leadership team to discuss these issues and what if any response IASA should make and where our responsibilities lie. I will be keeping you informed of any results we discover.

Follow up posts will include: IT architect liability and licensing issues, public inspection of IT systems, the 'doh! we didnt know response', and details on the case progression.

Patterns of Parallel/Multi-core Programming (Webinar)

2010-02-18T17:51:10Z

Every five to ten years the world of computer programming faces a new paradigm shift, like GUI, object orientation, or generics. Right now we are facing the paradigm shift of parallel/multi-core computing. Successful research in this area has been done for the past 30 years, but we are still not using the results efficiently. A pattern is a working solution to a recurring problem, and parallel/multi-core programming has its own problems which has led to a set of patterns. Come to a session about which patterns exist in the area of parallel/multi-core programming and how they can be used with Visual Studio 2010.

Tiberiu Covaci started his developer career in 1991, but wasn't until 1994 that he got introduced into the Microsoft world of technologies. He moved from Romania to Sweden 1996, to work as a programmer. Since 2004 he is working as an independent trainer, teaching .NET technologies on all levels, but what he loves most is teaching introductory courses, because it gives him a chance to influence the future .NET programmers. He works closely with Microsoft, both as Subject Matter Expert for the MCPD exams, and Technology Reviewer in the new Microsoft .NET 4.0 courses that are under development. He is a member of the MCT Advisory Council, INETA Speaker, and INETA Country Lead for Sweden. After the success he encountered at TechDays 2009 in Sweden he developed a passion for speaking about new technologies, and that made him a very popular speaker at conferences like TechEd, DevReach, TechDays, Öredev, ScanDev and MCT Summit. He is interested in technologies like multi-core programming, ASP.NET, new programming languages and trends, and applications security. Whenever he gets the time, he blogs at http://blog.multi-core.net/.

View Now

Austin ITARC 2010 Presentations

2010-02-15T16:53:34Z

Track 1

George Paras, Principal, EAdirections
EA Profession: What's Changing and What's Not?

Thomas Philbin, Sr. Enterprise Architect, Dell
A Case Study: The Development & Application of an Architecture Framework at Dell

Mark Bodman, Troux Technologies
A Practical Approach to Strategic IT Planning and Value

Tannia Dobbins, Enterprise Architect, AMD
EA: The Information Story

Track 2

Jeffrey Palermo, CTO, Headspring
CCS Architecture: A Prescriptive Take On Line-Of-Business Web Application Structure

Brandon Satrom, Chief Architect, Thought Ascent
Paul Rayner, Solutions Architect & Principal, Virtual Genius, LLC
Keeping Architecture Relevant: Using Domain-Driven Design and Emergent Architecture to Mangae Complexity and Enable Change

Track 3

Srini Penchikala, Security Architect | Speaker
Agile Architect: Integrating Enterprise Architecture into Agile and Lean Software Development Enviroments

Srini Penchikala, Security Architect | Speaker
Security Architecture Policy Enforcement and EA Governance Using AspectJ and SpringAOP Techniques

Security Architecture Policy Enforcement and EA Governance (Webinar)

2010-02-11T21:29:10Z

In this presentation, I will talk about the significance of enforcing security architecture rules and how to implement an application security architecture governance process in software development projects. I will discuss a framework we created, using Aspect-Oriented Programming (AOP) techniques and tools like AspectJ, SpringAOP, Eclipse and AspectJ Development Toolkit (AJDT), to identify any coding deviations from standard security architecture rules and design policies. The security architecture enforcement module was created as part of the overall Enterprise Architecture Governance effort to comply with Enterprise Identity and Access Management (IAM) standards. The session will include discussion on how to enforce the security policies in the areas of Authentication, Authorization, and Role Based Access Control (RBAC) as well as Security Domain Driven Design and Factory Object patterns. It's also used to enforce the security policies at execution time when users login to the IT systems.

Bio
Srini Penchikala currently works as a Security Architect at a major financial organization in Austin area. He has over 15 years of IT experience and has been working on Java projects since 1996, J2EE technology since 2000 and SOA since 2006. His main areas of interest are Agile Enterprise and Service Oriented Architectures, Domain Driven Design and Development In Practice, Aspect Oriented Programming (AOP), Architecture Rules Enforcement, Enterprise Integration Patterns, and light-weight middleware frameworks such as Spring and Hibernate. Srini is one of the organizers of Detroit Java User Group (http://sites.google.com/site/detroitjug/). He has presented at several conferences (ITARC, SATURN, Project World, and NFJS Symposium) and published articles on J2EE topics on websites like InfoQ.com, ONJava, DevX Java, java.net and JavaWorld. Srini publishes a blog on Java, JEE, and other topics at http://srinip2007.blogspot.com/.

View Now

Architecture Analysis - Reasoning About Structure (Webinar)

2010-02-11T19:32:25Z

This presentation is about fundamentals. Layering is a basic concept of IT architecture. Layers help to seperate dependencies and to decouple concerns. Most of the industry does layering in name only. It's lip service. In these slides and accompanying commentary we will explore the concepts of layering and isolation of dependencies and it's impact on the success of your architecture.

Speaker:
JEFFREY PALERMO is the CTO of Headspring Systems. Palermo specializes in Agile management coaching and helps companies double the productivity of software teams. He is instrumental in the Austin software community as a member of AgileAustin and a director of the Austin .NET User Group.

View Now

A Case Study: The Development and Application of an Architecture Framework at Dell (Webinar)

2010-02-10T19:40:31Z

Ever wonder how a Fortune 50 company "does" enterprise architecture? Tom Philbin is responsible for defining the Enterprise Architecture framework currently in-place at Dell. He will talk about the benefits that having a comprehensive framework for EA can bring as well as the challenges their team faced along the way. During this web cast, you will gain insight into the value of a well-thought-out and well-implemented framework for Enterprise Architecture.

Speaker:
TOM PHILBIN has over 15 years experience as an IT developer, strategist and leader. Tom has transformed businesses using Information Technology to significantly reduce costs and improve business capability, primarily at Honeywell International and Dell Inc. He has history of success leading people, generating value, establishing strategic goals and executing multiple complex programs. Most recently, Tom has played key roles in IT organization development, Architecting Dell's next-generation Supply Chain systems, developing Dell's Enterprise Architecture Framework, and rationalizing IT application portfolios at Dell and Honeywell. Tom's solutions have received industry awards (including the RealWare Award from InformationWeek's Intelligent Enterprise organization). Tom has been a featured speaker at industry conferences for his novel use of technology to solve business problems (including conferences sponsored by Dell, Honeywell, IBM and the National Security Administration). Tom graduated with honors from the University of Illinois and the University of Chicago with a bachelor's degree in Computer Science and a Masters degree in Business administration, respectively.

View Now

When and How to Use Event-Driven Architecture (Webinar)

2010-02-10T19:33:47Z

With the emergence and popularity of Service-Oriented Architecture, sometimes it is unclear when to use SOA and when to use a more advanced "SOA event-driven architecture." In this webcast, Nuno Godinho will cover the differences and trade-offs presented when applying these two approaches and show when to use each approach to maximize an application's quality attributes.

Speaker:
Nuno Godinho is an Independent Consultant responsible for helping customers to identify, plan, manage and develop software products and solutions. The majority of these software products and solutions are mission critical and use the Microsoft. NET platform from ASP.NET, Silverlight, Windows Forms, WCF, WF, WPF and even Mobility. He's been a speaker at major development events for Microsoft Portugal such as MSDN, TechDays and DevDays, covering subjects like ASP.NET, Silverlight, Windows Live Platform, Visual Studio and Windows Azure Service Platform, .NET Framework, as well as in International events like TechDays Worldwide Online and TechEd EMEA. Nuno has also been a Metro Instructor in topics like Visual Studio 2010, Windows Azure, Silverlight. His main services are Mentoring, Consulting and Advanced Training in areas like Solutions Architecture (SaaS, S+S, etc.), Development Methodologies (Scrum, MSF Agile and CMMI, FDD,TDD) and of course .NET Framework related technologies. His customers include public institutes, private companies, financial companies, and Microsoft Portugal. He's also an MVP in ASP.NET with blogs on http://pontonetpt.com/blogs/nunogodinho (Portuguese and English), http://weblogs.asp.net/nunogodinho (English and only about Web Development) and http://www.msmvps.org/blogs/nunogodinho (English) and http://xamlpt.com/blogs/nunogodinho (Portuguese), and also an INETA Speaker, INETA Country Leader for Portugal as well as Certified Scrum Master, MCT and so on.

View Now

Atlanta ITARC March 3-4

2010-02-10T18:25:49Z

3-4 March 2010 | Atlanta.

http://www.iasahome.org/web/itarc/2010/atlanta

Some reasons to attend: A strong regional focus. Receive case studies, best practices and individual training from senior architects-- many from your region including:

Kerry Holley, IBM Fellow and WWW CTO
Scott Ambler, Chief Methodologist/Agile
EA 2.0 Bill Cason , Troux Technologies
Patterns for Cloud Computing , Simon Guest, Microsoft.

A world class agenda of presenters from the top of our industry.

Conference Fee:

IASA Members: $650
Non-IASA Members: $950
Seats are limited and already filling quickly.

Please contact IASA Events +1 866 399 4272 or at events@iasahome.org or register at
http://www.iasahome.org/web/itarc/2010/atlanta

Where are the Enterprise Architects?

2010-02-10T14:25:57Z

As you can imagine I read a lot of architecture related books, blogs, news postings and watch even more presentations both online and at our IT Architect Conferences. Over the last couple of years Ive noticed a trend in EA presentations that claim there enterprise architecture is not necissarily related to technology. In this model of our profession, enterprise architects, model the business, or my favorite "architect the enterprise".

After 7 years of speaking with and leading communities of practicing architects throughout the world, there is much that needs to be said about this trend. First, let's deal with the language element. As my friend Richard Hubert has passionately described, the word architecture is a noun and not a verb. The verb that these folks are looking for is to design. I know, I know, you are thinking, "Paul that's just an expression. Why would you care about semantics?" Over these last 7 years I have learned to take language very seriously. Fundamental definitions impact the fabric of our profession. For example, in the expression "architecting the enterprise", mistaking the word architecting with design describes a profession where the word architecture is synonymous with design. I posted on this a while back, but if architecture is design then it is NOT a profession as ANYONE can design.

Another issue with this expression is the position it claims inside a business. If we are "architecting the enterprise", what are all the other business people doing? And what exactly does that mean? Does it mean if I create a business process model that describes our sales channel, it's customers and products with all the associated meta-data that I have "architected" the sales channel? If I propose a change to that sales channel have I then "architected" it? This definition of architecture starts to sound suspicious almost from the get go. It looks very much like "architects" moving to the head of the business table as business consultants. The only issue there is that we already have plenty of business consultants, MBAs, business executives, etc and they are not at all interested in us moving to the head of the table. They already have working models of the enterprise in the form of financial models, HR models, sales forcasts, and yes business process models. The folks that are recommending this are missing two critical factors in our profession; 1) it was technology that got us a seat at the table in the first place, and b) there are many thousands more technology architects in the world than there are non-technology architects (think 99% to 1%).

So where did the technology go? What distinguishes these folks from other business consultants? And most importantly to me, what value does anyone get from their use of the term architecture? Worse, are they doing damage to the concept of architecture as technology strategy? Building and maintaining a technology strategy for a company is a huge task. It takes a ratio of 6-10% architects to IT staff. It generates huge profits and enables that much more. So why do people continue to run away from technology as a key value proposition? For those of us that deliver a working technology strategy and don't 'architect the enterprise', there is enough work to do without trying to escape to 'the business'.

The new web portal - trends in 2010 (Webinar)

2010-02-09T17:51:25Z

In this presentation we will walk through the basic elements and types of portal and the enabling technologies that make them possible. We will venture into portal frameworks, mashups, social media and much more. We review the introduction of different technologies and how they have impacted web sites and where you might be able to leverage them to drive your own business.

Adnan Masood is a Web Architect / technical lead in a Monrovia-based financial institution where he develops SOA based enterprise applications, distributed systems, and Web-applications using the Microsoft .NET framework. A Microsoft Certified Trainer, Adnan holds various professional memberships (ACM, BCS,and ACS) and several technical certifications, including MCSD .NET, MCPD .NET, and SCJP-II. Adnan is attributed and published in print media and on the Web, holds a master's degree in computer science from Nova Southeastern University, and is currently pursuing his doctoral studies in machine learning. Adnan has taught Windows Communication Foundation (WCF) courses at the University of California at San Diego and regularly presents at local code camps. He is actively involved in the .NET community as cofounder and president of the of San Gabriel Valley .NET Developers group. Adnan is a recent recipient of an INETA Community Champion Award for his contributions to the developer community in Southern California.

View Now

Able Architecture: Part II

2010-01-26T04:36:56Z

From the Field

My name is Michael Montgomery and I am a practicing Chief Software Architect. Paul Preiss, founder & CEO of IASA, asked me to create an original column for IASA chronicling my experiences and perspectives of ‘slogging through the molasses’ moving a large architectural initiative forward.

From the Field is the result. A cathartic labor of love. Sometimes pedantic, at others irreverent, but always insightful (in theory at least). To find other articles in the series, search on ‘From the Field’.

I hope my observations inspire you to also share your comments and experiences through which we can learn from each other and ‘master the molasses’.

Able Architecture: Part II

Part II of Able Architecture continues to reveal my vision of Modern Software Architecture.

Acknowledgements

I would be remiss not to mention that I was introduced to the core ideas expressed in this article through the teaching, authorship and mentorship of Juval Lowy, Master Architect in the Microsoft Practice and general visionary. I am also a practitioner of the IDesign Method. Seek more at IDesign.

Straight from the Front

As I mentioned, I’m a practicing Solution Architect. I am also the lead architect on a very large SOA initiative. As one of my previous articles, What Mean You, SOA? prescribes, it is up to me to have the vision. So blood has been let. Sacrifices made. Molasses slogged and the oracles of hard fought wisdoms consulted. What remained was a powerful vision indeed.

It has been 10+ years since the industry started its romance with this little acronym we call SOA. And in 2010 the verdict’s still completely out on its benefit and viability. In fact at the beginning of 2009, SOA was deemed dead in a blog shot heard around the IT world. A blog shot that was dead on to the truth of the situation, but unfortunately no one (especially the press or anyone on mahogany row) bothered to read the whole entry. Every CEO, CTO, Dev Manager and industry pundit should reread that entry and fully appreciate the truth at the end of it. I think every IT executive jumped on the byline because they didn’t want to face the reality presented between the lines: true SOA adoption is ultimately a violent evolution (revolution??). CTO’s can you say “Throw out everything you thought you knew?” and “Complete rewrite”?

So now there have been volumes of books written about it. Multiple compendiums constructed in its honor. One recently published memorial is comprised of upwards of 5 books each topping out at over 800+ pages! And what is missing for every single one of them? Why a clearly defined, easy to adopt, straightforward, formal approach to SOA Design of course. Could this suspicious void be the real reason why the majority of SOA initiatives have failed historically and continue to fail today?

As I declared in Part I of Able Architecture:

“Without a clearly defined SOA Design Process, developers inevitably produce services that look and feel just like objects. This is a sure smell that the architecture will ultimately collapse under its own weight and eventually fail, becoming a maintenance nightmare.”

What follows is a rough abstraction of what I consider to be without question the single most crucial element of any progressive Modern Development Process (wait for Part III for that vision) meant to produce Modern Software Architecture, a formal SOA Design Process. Without one you are lost.

As with much of my current work, this abstraction has been informed by the IDesign Method, brainchild of SOA impresario and visionary, Juval Lowy and his team at IDesign.

So no more messin’ ‘round let’s get into it directly (and I hope the MOA guys are paying attention).

Vital Signs

This is the list of vital aspects without which you cannot continue. The list is by no means exhaustive, but then exhaustive lists are a thing for which we are not. Exhaustive lists are, after all, exhausting, leaving you spent before you’ve even done anything. And to me they often carry the scent of the bane of our discipline, over engineering. Yes, you certainly can move forward without knowing everything. This is why we iterate on everything, including our process (more on that in Part III).

While many may read this list and think, “…but of course.”, you may be surprised, as am I, that none of the contemporary approaches toward SOA Design being currently pandered satisfy even a few of these vital aspects. Don’t ask me why. I will tell you it’s my observation that they all seem to lose their way at some point and become completely convoluted. Design by exception is not where you want to be.

Perhaps it’s the desire to be all to everyone. Perhaps it’s the desire to be the Grand Unified Theory of SOA. Don’t know. I do know that if you can’t sum up your SOA Design Process in 10 pages or less then you stand to a 0% chance of absorption, adoption and advocacy within a development community composed of a diverse technical acumen. Never forget that there is a fundamental point to all this; to get a job done well. As Architect, it is your role to lay out the vision for mass consumption. Trust me; you’ll need every last developer’s help to bring your vision into reality.

These things are in no particular order, though I see the one that is quickly becoming my favorite, because it makes such a splash with those outside of the Dev Box (and because it is truly the Holy Grail of our discipline), is last.

Modern SOA Design must:

1. Be sub-system focused

2. Be use case driven

3. Be defined by a small collection of concepts

4. Provide a simple set of governing rules

5. Provide a simple, understandable modeling nomenclature

6. Clearly convey multiple system aspects

7. Translate directly to code

8. Directly support Business Agility

Something to Chew On

Modern SOA Design must be sub-system focused. This aspect may be the simplest of ideas, but I‘ve come to appreciate its profound effect. As any wise engineer knows, to try to see the whole system is to go blind. It’s impossible to reason about a large complex system in its entirety. The whole must be broken down into a collection of sub-systems, each of which represents a level of granularity and autonomy that a small team can chew on.

Modern management ideology recognizes that small teams of 3 to 7 members perform best. Go beyond this and negative turbulence increases exponentially, things begin to fall apart. This is also where SOA meets Agile. The sub-system delineates the Sprint. Some brave visionaries have even tried to translate the fundamentals of service-orientation into managerial techniques, literally.

When you assess your problem domain, some chunks (i.e. feature sets) may announce themselves as self-evident sub-systems. Others do not reveal their fault lines until they’re placed into the crucible of design analysis. Talking through a domain’s workflows often reveals volatilities, autonomies, differentiation and new sub-systems.

A sub-system focus also directly supports the Axioms of Architecture, particularly high cohesion. This is one of the many places where SOA meets DDD (Domain Driven Design). The sub-system is the context.

Drive-By Use Cases

Modern SOA Design must be use case driven. Ah, use cases. Still, even now they are the absolute foundation of our discipline and the linchpins of good process. They are the admittance that you have chosen the enlightened path, that you know nothing and must be filled with the details of domain.

The pursuance of use cases must force you to leave the comfort of the Dev Box and inquire. If you do not, who knows what the hell you’re building. At least that’s what your end users will ask. Use cases are what all those industry pundits are talking about when they spin obtuse verbiage like, “Realized Business Value” or “Business Operation Alignment”.

In my current work, we have found that by aligning requirements directly along use case boundaries, business operations fall right out and into service operations at the appropriate level of granularity. In fact, we’ve gone as far as to express use-case flow charts as simple requirement lists. Each of which becomes a service operation on an architectural concept responsible for use case orchestration.

Another benefit that a use case driven approach provides, is the opportunity to validate the architecture simply by walking through the use cases and confirming that the architecture addresses each.

Conceptually Speaking

Modern SOA Design must be defined by a small collection of composable architectural concepts. Any astute Architect who has studied some of the contemporary SOA Design approaches knows they all fail this aspect. Without exception, concepts abound.

This aspect is essential. As mentioned earlier, absorption, adoption and advocacy within your development community for your SOA Design approach directly depends on its ability to mitigate complexity. One face of complexity can be seen in architectural approaches that are teeming with concepts. There are simply too many options.

While it is the job of the theorists to codify all the patterns relevant to the SOA paradigm, it is the primary responsibility of the Architect to understand and distill these options into a succinct design approach focused on the needs of their domain. As with any engineering discipline, this distillation process involves the hard work of formalizing the core values of your architecture and balancing the tradeoffs. Each domain often needs only a handful of concepts, whether you’re crafting service oriented applications, legacy interoperability facades, service buses or forwarding solutions.

Believe it or not it is my experience that any given domain requires but a handful of architectural concepts to be fully expressive. Composability of these concepts is the key.

Keep it Simple, Guv’nor

Modern SOA Design must provide a simple set of governing rules. To a fault, this is one aspect that every approach seems to trip over itself to ignore. They just can’t help themselves. Either the rules go on and on or they are completely nonexistent. The latter actually happens more often. Contemporary approaches often spend an exorbitant amount of time defining endless SOA patterns, but say nothing of the rules that must exist for these patterns to peacefully cohabitate.

SOA Design rules are all about ensuring that the Axioms and Aspirations of Architecture are preserved. The most important rules define the allowed relationships between architectural concepts. These rules are put in place to serve and protect loose coupling. Other rules define what can and cannot be placed in a given concept, which clearly define layering and encapsulation.

It is my experience that this aspect also goes hand-in-hand with the previous aspect. The more architectural concepts you have, the more rules you need. The more rules you need, the more exceptions to the rules you must provide. The more exceptions you must provide the more decisions that must be made. The more decisions that must be made, paralysis ensues. Decision paralysis is an evil that can bring an entire org to its knees. It is essential to keep the rule set short, sweet and succinct.

Model Glue

Modern SOA Design must provide a simple, understandable modeling nomenclature, yet another vital aspect. As the industry is quickly realizing, modeling is essential to SOA Design. You simply cannot reason about the many facets of a design without a model. These are the blueprints of our endeavor. (This is architecture after all. What would it be without blueprints?)

But again, your model must be easily understandable or it is worthless. This means that your modeling nomenclature must also be simple and succinct. It must also be highly consistent. Taking a tip from our big brother disciple, Building Architecture, construction blueprints keep their nomenclature simple by defining a small number of drawing elements and recasting their roles based on their context.

This means something like a simple red box can have a different meaning depending on the context in which it’s used. This also means that modeling elements must be simple graphically. I mean really simple. Like box and line simple. Anything more and the graphics just detract or distract from the problem at hand.

To also keep them simple, models must not over convey. They must stick to conceptual intent and not delve into functional specifics. Over granular modeling couples the model directly with logic, which is not the intent of modeling.

If your modeling approach is clicking, these simple diagrams become the centerpiece of conversation. When developers spin up their design blueprints instead of their IDE, good things are happening.

Multiple Personalities

Modern SOA Design must clearly convey multiple system aspects. Modeling must not only express architectural composition, but also provide diagrams that convey other system aspects as well.

In addition to architectural diagrams that reveal operation call chains; your architecture must also include diagrams for such things as identities and transactions. These diagrams reveal how these important system concerns lay over the architecture. Another set of diagrams must inform others on the details of binary allocation, process boundaries and logical service dependencies.

By conveying these additional aspects the architecture also gives a little love to groups outside the Dev Box. Disparate groups such as Build, Test and Implementation can use architectural diagrams to make informed decisions. This helps both you and them express the architecture correctly. (And greatly reduces the length of the queue lining up at your door.)

Continuous Spectrum

Modern SOA Design must translate directly to code. If the many aspects of your design can’t be expressed directly in code then again your design is worthless. I suggest viewing your architecture as a continuous spectrum from design to code. When someone familiar with your design looks into the code that expresses it, they should already know what they’ll find.

Binary allocation diagrams have defined the project layout and names. Concept names not only reveal their role, but directly match those in the architectural diagrams. Transactional flow should be evident based on the expressiveness of your middleware, as should identities.

Since they should already know the role and purpose of each concept type in your architecture, they should know what to expect when they peer into any one of them. They’ll know where the SQL resides, as well as the business logic and where use case orchestration can be found. Additionally, since your architecture is highly self-similar all instances of a given concept type are expressed is a very similar fashion in code.

I cannot stress enough how vital a self-similar architecture is to dynamic team composition. Once your developer community is familiar with your SOA Design Process and the code meant to express it, developers who are not domain experts can come and go on sub-system teams and contribute almost immediately without a lot of ramp up.

The Holy Grail

Modern SOA Design must directly support Business Agility. Ah, the Holy Grail of SOA. It sounds so nice, doesn’t it? Wouldn’t you love to walk into those meeting and confidently pronounce, “Yes. We can do that.”? This is where diligence, discipline and determination toward your architectural values and SOA Design Process pay off.

As defined in Part I, “(business agility)… means that the same software can easily expand, contract or morph into new forms to quickly meet business needs.” Formalizing your SOA Design Process and establishing rules that directly support the Axioms and Aspirations of Architecture (see Part I), ensure opportunities for expansion. Endpoint locality can become dynamic. Both homogenous and heterogeneous scalability are supported. Internal service orientation is possible and the encapsulation of use case orchestration can mitigate the coupling needs of context specifics. All of which provide the architecture a high malleability index.

These expansion joints provide both you and your clients dramatically improved business agility. They allow you to command a proactive instead of reactive stance. New features become capitalizing opportunities, instead of difficult adjustments. Your clients can reap the benefits of the same software growing with their growth with little administration cost.

The artifacts of your SOA Design Process also directly support agility. Models provide pivot points for problem reasoning, identifying architectural relationships and communicating with other groups. Change management becomes very dynamic, without initially touching a line of code. Modular deployment is also supported, since change impact can be easily understood.

In the end, it is the SOA Design Process that will lead and keep you on the path toward the Holy Grail.

Able Architecture: Part III

To conclude the Able Architecture series, Part III will outline the Modern Development Process I currently run. As you might guess, the SOA Design Process sits as the crowning jewel, central to it all.

Guest

Age of Collaboration E-Summit

View Now

Atlanta 2010 ITARC Presentations

Keynotes:

Enterprise Track

Infrastructure Track

Software Track

Fundamentals Track

A Turning Point for the Government Cloud

Review - Real Enterprise Architecture

Review - Enterprise Architecture Models and Analysis for IS Decision Making

Article: SOA and integration in the cloud bring agility and value down to earth

Whitepaper: Examining the Business Value of SaaS Integration

Webinar - SOA Core Services

Model Oriented Architect Webinar Software Architecture using Model-Based Approaches

Thoughts on the Robbins v. Lower Marion School District - Student Webcam Remote Activation

Patterns of Parallel/Multi-core Programming (Webinar)

View Now

Austin ITARC 2010 Presentations

Track 1

Track 2

Track 3

Security Architecture Policy Enforcement and EA Governance (Webinar)

View Now

Architecture Analysis - Reasoning About Structure (Webinar)

View Now

A Case Study: The Development and Application of an Architecture Framework at Dell (Webinar)

View Now

When and How to Use Event-Driven Architecture (Webinar)

View Now

Atlanta ITARC March 3-4

Where are the Enterprise Architects?

The new web portal - trends in 2010 (Webinar)

Able Architecture: Part II