|
|
-
When: October 8-9th Where: Omni Shoreham Hotel, Washington DC Registration link: Register online here Description of the Conference: The response to the Washington DC ITARC has been amazing. Attendance is way up thanks to many organizations sending their entire teams. 
Refer a Friend and Win A Zune! Send out the email to a colleague or a friend. Have them put your name in the Referred By box when signing up. Whoever gets the most wins! Please take this opportunity to help us really blow the doors off of our first Washington DC conference. All you have to do to support your chapter is send out this flyer and attend the event. - 2 day, 4 track event for 75% cheaper than any similar event
- Revenue goes to support local services in Washington DC
- Developed and run by Washington DC architects for Washington DC architects
- Great turnout this year = a bigger and better event next year at the same low price
- Discount code for friends and co-workers for 10% off: partner436
The conference only holds 300 so get registered today. ITARC 2007 Agenda - The following lists the sessions available at the event. Attendees will be able to get a DVD with ALL sessions from all three ITARC locations (over 100 sessions). Check out a few of the events awesome lineup of speakers - Key Notes:
- Keynote: Where We Go From Here -- The Future of EA in Government
Richard Burk, Chair Chief Architects Council, Chief Architect, OMB - Keynote: How to be a Successful IT Architect, Angela Yochem, IASA Fellow, SVP, Strategic Architecture Management Executive, Bank of America
- Keynote: Large Scale Infrastructure Architecture - the MSN Challenge, Michael Manos , Chief Infrastructure Architect, Microsoft MSN
- Keynote: Models and Success
Fred Waskiewicz, Director of Standards, OMG - Enterprise Architect Track
- SOA Maturity Models, Steve Wolf, CTO, Marriott Hotels, Int'l.
- Daniel Brookshier, NoMagic
- Success in Enterprise Architecture through Collaboration, Craig S. Connell UniStar Nuclear
- Models and Governance in the Enterprise ,Mark Foster, PM Customer Deployments, Troux
- Service-Oriented Enterprise Architecture ,Yan Zhao, Director of Enterprise Architecture, CGI Federal
- Infrastructure Architect Track
- Software Architect Track
- Fundamentals Track
Click here to take a look at the full agenda. Registration Register before September 10, 2007 to receive a $100 discount. IASA members receive an additional discount in addition to the early bird special: Register by September 10, 2007 IASA member
Non-member $350 $500 Register after September 10, 2007 IASA member
Non-member $450 $600 Click here to register online Click here to register by check or all 512-615-7900 Questions or comments? Please contact events@IASAhome.org.
|
-
In the last step we decided that a combination of federation and centralization will suit the enterprise best. So the underlying question is; what parts are centralized and what parts are federated? The answer is ... it depends! There are a variety of factors that go into the choosing. Lets go over a few of the big ones. Remember, we don't need to 100% right, just close enough to engage the rest of the team in the conversation. Question: How tightly or loosely coupled should the parts be? Coupling is a subject tossed about at all levels. Components, applications, services, and architectures all debate when some is ok, more is better and too much is, well, too much. I do believe the consensus is to limit tight coupling within the architecture to allow for future changes in the enterprise. There are any number of good patterns to accomplish this. Edge services and providers comprised of Brokers, Plugs, and Adapters to monitor and react to the current state of things, some variant of Bus can provide an architectural channel separating participating parts as well as creating a mechanism for implementing canonical semantics, or simple facades could be used to present and transform on a boundary. For Message2You, the choices are driven by the current environment. Organization defines architecture. As a small company Message2You is setup as a light weight hierarchy. Cxo level managers have regional manager as direct reports. This is important. The architecture for an enterprise organized round business units tends to be strongly centralized with each business unit using most if not all shared corporate capabilities. Enterprises that are organized around geographies tend to be largely self supporting in each region and only lightly touching the corporate core. Here is an example of an enterprise that supports business units with shared corporate resources; 
compare that to a more regionalized enterprise; 
This second view looks like a good place to start. The enterprise architecture has three major components areas to refine; - Shared services such as Security, logging, and Client update or patching are technical in nature and centrally controlled. Nothing but chaos comes from allowing each region to dictate is own version of these services. Next we have
- centrally provided services such as Directory, Service Discovery, Broad resource management (hire/fire etc...), Broad Budgeting and Finance. These differ from the shared services in the way they are implemented. Shared services are created centrally and implemented in each region as well as the core while centrally provided services are created and reside in the core with regions implementing a mix of client access and region extensions. Last are
- regionally specific services. These are unique to the region implementing them. They may or may not have any interaction with the core. Examples of regional services might be local payroll or workflow and rules engines.
Next step: Select specific implementation architectures for each interation within the enterprise.
|
-
During the last step we began scratching the surface of the needs of the enterprise. Clearly it was too broad a description to make any significant architectural decisions. Agile practices provide us a simple and effective approach to address this... "involving the customer". As we begin assembling the architecture we need to repeatedly, on might even say incrementally, engage the many representative communities the architecture is intended to support. But how best to do this? How do we create something light-weight and easily consumable by application users, Project leads, IT managers, and CO's? Personally I am a fan of the "Boxes and Lines" model so lets run with that for now.
For a macro level architecture a "Boxes and Lines" presentation might look something like this;
When we use Peer to Peer and the intent is to make every participant equal. Or maybe this;
a Centralized approach where all the participants share a single core but don't interact with each other. Another alternative might look like this;
A federation of participants comprised of mixed communication networks. Most participants work autonomously but choose one or more relationships within the federation.
Lets look at each and how well it does or doesn't support the enterprise. In our fictional organization, Message2You we have a few guiding comments to consider;
- Organizations can enroll individual or groups of users Users as well as create non-user specific roles to receive messages.
- Messages are validated, distributed, and secured against customer supplied rules.
- Organization admin's can receive near real time status on individual messages and "correct" messages that fail to make their way through the rules gates.
To this lets add a few more things learned during our on-going conversation with individuals throughout the enterprise;
- Changes made to a customer supplied rule need to effect every message immediately.
- Some messages must be processed ahead of all others,
- Some user organizations may not use a standard directory for their addresses, and last
- Message2You wants to buy more than they build. Currently they have most of the Microsoft platform; Exchange, SQL, Office, etc...
So, are we looking at a Peer to Peer, Federated, or Centralized Architecture for Message2You?
Peer to Peer is a contender but isn't a great fit for an implementation that needs to propagate changes quickly to all points. It would however be a good choice for a highly reliable system and spreading the processing load may also prove and excellent way to scale without negatively impacting user perceived performance.
Centralized looks great on the surface. Most of the control, monitoring, and performance issues are quickly settled in a centralized system. It presents fewer moving parts and limited deployment issues. Centralization fails to support multiple independent customer organizations.
Federated addresses the multiple customer organizations by allowing each participant solution to work as independently or as connected as it might but fails terribly on rapid dissemination of change as well as it's increased management and monitoring complexities.
If none of the macro architectures work what do we do? Well there are two possibilities; first we can address the requirements and scope. It ay be possible to negotiate with our customer and re-define success in such a way that it will better fit one of the macro architecture patterns. Second we can look at combining the macro architectures and into a more problem specific composite architecture.
I'm lean strongly toward the composite architecture. One that provides the autonomous support of the federated architecture with the ease of management and responsiveness of a centralized architecture. I do not see the need for a peer to peer implementation with the requirements as we know them, but that may well change as we discover more. For now lets use this as a starting point;
This approach is centralized in that all the participating organization are required to use a centralized "core" to interact with any other organization while it has traits of federated allowing each participating organization to operate with some degree of autonomy.
It's still not enough to engage the customer in discussion. For that we need to go down another level of detail and really begin to make it address the specific issue of the Message2You enterprise.
Next step: Further refining the architecture
|
-
Now that we have gathered some initial information we need to sort it out. Actually its more complicated than just sorting, we need to find the patterns in what we have as well as see the missing parts for what they should be. Here's how I do it;
First I grab a deck or three of blank 3x5 cards. I like the cards so I can write in any direction and draw ... well doodle really ... pictures of things. Most cards get titles reflecting some kind of logical architectural component. A few of the more common titles include; Security, Notification, External Interface, etc... I read through everything start to finish. Speed learning is part of the job. Whenever I find something interesting I note the source, the page, and the item on a card. Sources can be PPT "milestones for Foo project, Sept-04" or conversation with Bob 4-Jan.
The idea is to capture all of the high level concepts like "message based" and low level items like "Current systems prefer UDP" and general items such as "No HelpDesk" on separate cards. It quickly becomes a memory game. Every time I find something new it is either added to an existing card or gets a fresh blank one.
Early on I might create a card for federated architecture. Later when I note disconnected user it helps to put the two together. Coming across the need for "Instantaneous world-wide changes to security" will, contrary to the prior two, create a centralized architecture pile. This is just the first pass so orthogonal requirements are allowed. Once I feel like I have made a good run through everything I shuffle the deck and re-sort the piles. Sometimes they end up exactly as they were but more frequently than not I end up with a new organization.
Lets look at a fictional organization, Message2You.
Message2You provides a rule based message handling system that integrates with Microsoft Outlook and Microsoft Exchange. Organizations can enroll individual or groups of users Users as well as create non-user specific roles to receive messages. Messages are validated, distributed, and secured against customer supplied rules. Organization admins can receive near real time status on individual messages and "correct" messages that fail to make their way through the rules gates. A quick pass on the cards might look like this (please forgive my handwriting, spelling, shorthand...);
These cards group the message processing items
Here are the client side update and External Interface (EI) cards
Workflow and Notification
and last but not least, Disaster Recovery, Security, Patch Management, etc ...
In the next step we will turn this into a rough logical model
|
-
Back from our information safari, its time to munge (that’s a technical term) through the end-users naratives(stories), legacy systems information (relics), and our own notes (journals) collected along the way in hopes of piecing the truth together. Not just any truth, no we need to find a version of the truth that is both universally acceptable across the enterprise and internally consistent. No one item is likely to be complete. Most represent a single instance of a small portion of the broad enterprise. Taken together we still won’t have a complete picture. We can however knit together the parts that fit, extrapolate a few more, and apply our best estimate as to what might fill in the remaining empty spaces. Let’s do a little walk-thru of the spoils. The largest collection may well be user stories. I love these. I have yet to meet an environment where everyone from upper management to line worker wasn’t delighted to tell stories about what they do every day. I am careful to refer to these as stories. Poetic license is expected and encouraged. We need to get the flavor of the activities, the politics, and the priorities, along with the tasks and their steps. Everything, from the monthly birthday parties to the distribution of paychecks conveys something worth getting into. If nothing else, there is also a tremendous amount of good will gained by simply giving your time and listening to others. Earn it now, you will need it later. These stories can be characterized as incomplete static and dynamic views with easily attributable sources. Next we have the relics. When discussing the day to day goings on in an organization people tend to refer to things; phone books, manuals, memos, etc … when ever possible I ask for a access to or a copy of “it”. The good news is placed in the context provided by the source, there is a tremendous amount of information in relics. The bad news is that you are duty bound to read everything you get. It is insulting to your source to get a relic only to bury it without review … read often, read fast, take good notes. Relics frequently provide static views and doctrine. There are definitive but may well be widely ignored in the real world. It’s up to you to decide which is right. Journals are tricky. These are your notes. Mine tend toward seemingly endless pages of nearly illegible scratching. Partial sentences interspersed with the odd doodle. Sometimes there are drawings made by the person I’m talking to in a generally futile effort to get me to understand the relationship of process A to process D. Or was that a B? The point is, you need to review, edit, and generally translate your notes often. Daily works for me. If too much time passes you will likely loose some of the original fidelity. I like to capture quotes when possible but I find a lot of my notes are really odd abuses of the Unified Modeling Language (UML). Now were getting to the real meat of the effort … Next step, Decomposition and Analysis
|
-
In Step 3, I touched on how legacy choices might significantly impact the design of enterprise components. Now we need to incorporate the broader needs of the business into our design which will likely reverse some of the simplifications applied in the last step. Establishing a sound basis for changing our simplified design is as much mandate as requirement. We need to make our decisions with reasonably comprehensive knowledge of the entire business domain. Of course achieving this requires balancing our need o conduct research and analysis with the limited time to do so before the domain changes again. With fresh eyes we need to discover (or rediscover) the enterprise. We need to venture forth, leaving our cubicle, going beyond the comforting borders of the IT department, and mingle with the business in action Questioning everything and assuming nothing. When gathering information about the domain you should; - Leave the laptop behind; I, like many, can type faster than I can write with a pen. Non-the-less, I abandon the laptop for a pad of paper when I am researching an enterprise. The laptop has a way of coming between me and those I speak with. The clicking of the keys always breaks the otherwise natural rhythm of conversation and keeping eye contact becomes, at best, difficult. I would like to believe a slate or tablet pc is a middle ground but I haven’t had the privilege yet.
- Use Interview not Interrogation techniques; There are few populations as affected by television as software developers. The vast majority of developers turned business analyst I have worked with seem to have taken their interviewing style from police dramas or investigative news shows. You should avoid direct positive confrontations. Instead of saying “don’t you usually look to minimize over burdening people in the schedule?” consider, “ are all people scheduled the same way? if so how do you manage to balance things, if not what differs one person from another?” Avoid developing a theme for the people your speaking with, instead look for themes they present to you.
- Avoid System terms; as users of tour echnology become more and more comfortable with how technology works they tend to translate their thoughts into our language. They mean well but don’t let them. Finding out that someone clicks a button and updates a record in the database simply doesn’t help us at this point. We need to know why they are acting on the entity or thing whose attributes are persisted in the database. What are they trying to accomplish?
- Lead gently and Listen intently; we need to provoke thoughtful consideration of the business tasks and how context, workflow, and constraints affect them. This is verbal geometry. Our theorems require proofs. If someone says they receive some information to process, ask where it comes from, does it always come from the same source, is it always the same format? Find the pattern in content, schedule, etc ...
It has been said that all arguments are good. You either prove you are right or you are proven wrong and provided the opportunity to correct your own misunderstanding. While we should striver to avoid the negative aspects of arguing, we must challenge our customer and ourselves. As architects we bring technical understanding to the resolution of business issues as often as we bring business understanding as guidance to the technical solutions. Constantly seeking to define the implicit activities of the domain in explicit terms so that we may validate their accuracy and completeness helps us map our understanding of the domain and identify it’s impact on how and where we apply technology.
|
-
Selecting the right mix of abstract and domain components is crucial to achieving an appropriate balance between investment and return. Many a project has fallen into the tar pits of extreme analysis and overly complex inheritance hierarchies. It may seem academically correct to root all entities in a few abstract base class such as item and person. After all, what isn’t an item? Documents, supplies, parking spaces, are all items in their own way. The danger is in the details. Consider a single students class schedule. To fill a grid with a single semester’s information we might need to create instances of person, student, faculty, location, facility, time, calendar, item, document, and schedule. 
Seems a bit heavy handed. So what is a viable alternative? As with so many things related to design, it depends. It depends on the limitations and capabilities inherent in the technology you chose to implement your solution. It must pay homage to any known constraints of the deployed environment, as well as work with the skill sets of the staff. For this example; - I am using Microsoft products,
- I have a capable but less than robust network,
- I will be serving a few thousand users who are spread out over several hundreds square miles but at least they are all in one time zone,
- Security is important but not mission critical within a user type (if one member of the faculty sees another’s schedule … no problem. However a student should never see another student’s or any faculty information.)
- Management wants to conduct “what if” analysis of the course schedules and related faculty assignments,
- The team in predominantly mid level coders with a mix of Java, .Net, SQL server, and Oracle backgrounds, but has one very strong .Net developer as its lead.
The immediate effects these constraints imply include; - Being more stateless than not,
- Using OS based groups and roles,
- A high likelihood of implementing data level replication so that a given population is as close to their data as possible,
- Possibly creating a separate reporting facility for management, and
- Using a real database to perform fast aggregation activities.
I would consider a significantly simplified design, more like this; 
Schedule is arguably a core element in the domain. It interacts with nearly all of the other elements in the domain. It is certainly worthy of the creation of a simple callable façade. The heavy lifting, the aggregation of the various components of the schedule are delegated to the database engine via a stored procedure. This allows use to implement security, pooling, partitioning, and replication. At the heart of the action is the need to find the union of the various datasets. The database already has the current values used to calculate a result. Our tool, in this case SQL Server is a highly performant, scalable set theory processor. In addition to meeting the needs of the environment, it limits network consumption by avoiding the various inter-object calls and their calls to the database for state information on construction. Additional entities would be added AS NEEDED. Architect for the largest possible known solution but build the smallest, simplest solution possible. So what is the right mix of abstract and domain components for your enterprise? Here are my top three questions to ask your self; 1) What applications exist today (real and imagined) and how do they overlap? In some circles this is called the enterprise portfolio. Assuming you are not looking to do enterprise re-engineering, you need to create a map of the users and their tasks across the entirety of the business. No other exercise will give you the breadth and depth of understanding needed to identify the core entities and services suitable for promotion to Domain component. 2) What is the direction of the business and what might change? It would be a best unfortunate to establish domain components representing aspects of the business about to be sold abandoned, and negligent to fail to account for a portion of the business slated to be acquired. 3) What, in real numbers, are the capabilities and weaknesses of your IT infrastructure? Enterprise solutions require communication and in our case that means networks. If they are ineffective or missing entirely you might want to push enterprise architecture off for a while. If they are in some areas than others, you have an opportunity to work with the IT infrastructure teams both identifying the issues and [balancing the usage or their prized assets.
|
-
Enterprise architects are responsible for providing simple, effective, enterprise worthy, domain components to the application developers. So what makes a good domain component? - It must provide quantifiable BUSINESS value over time. This may be the result of lowering the time and related cost required to build applications implementing the component. It may be the result of reduced helpdesk costs by standardizing error messages. It may even be the result of improved utilization across development teams by reducing the learning curve associated with each application startup. Regardless of exactly how the value is achieved it must be clear how the business will be impacted and what changes to process are required BEFORE you build it.
- It must be broadly applicable across applications in the enterprise portfolio. In most organizations broadly could be interpreted to mean as few as 3 or as many as all applications. Broadly applicable components tend to make themselves available as directly callable, inheritable, or implement-able classes.
- It must be stable, or at least built in such a way as to prevent future changes from damaging the applications that depend on it. Tool selection has a tremendous impact on this one. Using .Net, we can leverage things like side-by-side deployment, interface classes, and loosely-coupled events. Each component design needs to meet the minimum requirements for an enterprise worthy component.
Compare that to what makes a good plumbing component; - Provides system level services (logging, transaction management, etc…) to any calling component
- Capable of providing their services in more than one business domain with little or no modification,
- Don’t affect the facts being acted upon by domain components. This is an odd but consistent pattern. Data access components don’t impact the transaction they enable it. Logging components write what is passed to them without change.
As an industry we are just starting to create plumbing components for broad consumption. Microsoft’s Patterns and Practices site (http://www.microsoft.com/resources/practices/code.mspx) has several well thought out plumbing components. These are perfect fodder to kick-start the lowest level of enterprise development. Personally, I have great hope that we, as an industry, will begin to implement the plumbing behind a higher level of abstraction targeting specific Domains. Consider a school system. One would think an enterprise approach would provide components for Students, Faculty, classes, facilities, and schedules. We could logically extend this to create a layer between the domain components and the plumbing which might include, time, location, person, and organization, with a structure something like the illustration below.
 Application developers could use these domain parts, without knowledge of or any need to muck with the underlying plumbing. They need only add some application specific parts, stir in the needed logic, and test well at 400 degrees for 30 minutes … and poof, one enterprise compliant application. I don’t mean to over simplify a truly complex task. Creating an API is high art. Extending that API to object models makes it staggeringly complex for those who create them. However, this is our mountain to climb. This is the hard work that we as enterprise developers need to suffer so that all (enterprise, developers, customers, and end-users) may have their cake … robust enterprise class products… and eat it too … quick, less expensive, less complex application development.
|
-
Application development code is too focused and too volatile to be promoted across the enterprise, and enterprise code is too generic and too hard to change for it to precisely address application needs. Coming to an agreement on these ownership / boundaries within the enterprise is critical for the intertwined success of all parties involved. As a first step, I am proposing a simple ownership scheme. Given the four major types of binaries (user, application, domain, plumbing) along the X axis and application and enterprise developers along they Y axis. We can plot two curves reflecting who the "level of influence" assignable to either the developers or the enterprise. (see figure below)  The separation is not artificial, and reflects three very important principles; - The enterprise can not shift the responsibility for the creation of enterprise parts to the application developers
- The Application needs can not drive the components developed for the domain or their supporting plumbing
- The enterprise should not do anything which drives the way an application addresses specific application needs or the presentation related to the same.
Next, we will look at implementing the parts within the control of the Enterprise Architecture.
|
-
High quality applications are simple. They do some one thing well. The classic example is the famous Hello World app. It simple displays the text back to the caller. While there are vast language dependant permutations lets follow our own advice, keep it simple, and stick with C#. using System; class HelloWorldApp { public static void Main() { Console.WriteLine("Hello, world!"); } } Simple, Easy, effective … what more could one want? How about making this enterprise ready. First we need to get more serious about what Enterprise Ready means. On the short list, and enterprise ready application would; - Comply with the enterprise architecture
- Use existing components for common tasks
- Data access
- Logging
- Rules
- Be extensible over time
- Implements the façade pattern
- Separates GUI from business implementation from data access
- Be flexible once deployed
- Provides variables outside of the compiled code
- Support multiple languages
- Be secure
- No trust at machine (maybe even component) boundaries
- Communications are not in clear text and keys, if used, are securely stored
Left to fend for itself, this is nearly punitive overhead for a simple application. To keep it simple and meet the enterprise needs the people responsible for the enterprise architecture need to provide the parts and examples on their application (not their internals) to the developers. If the enterprise parts exists the changes to the code may be a few extra parts and a few additional lines of code. A client windows application will need to be built to call a server hosted façade. The façade would implant the enterprise security and call a refactored, generic text handler. Except for the text handlers overloaded interfaces, it need only know about the enterprise data access component. Every thing else would be invisible to the developer. By most estimates the application would still be considered simple; Windows form code; private void button1_Click(object sender, System.EventArgs e) { myFacade myF = new myFacade(); CultureInfo cu = new CultureInfo( "es-ES", false ); string s = myF.getText(text, cu); this.textBox1.Text = s; } Façade code; using System; using System.Globalization.CultureInfo; namespace MyCompany { public class getText { public string getText(string text, CultureInfo cu) { string s = MyCompany.Dattacess.getCutlureText(text, cu); return s; } } } Complexity for the enterprise is provided by the enterprise; - The text handler would get text from a database or resource file using an existing data access component, and ensure the connections a managed and the correct language is returned in the appropriate character set.
- Access controls would have been established and implemented in groups and roles
- Logging would happen by attributing the appropriate interfaces in the data access class.
- The users identity would be flipped to a generic application role which would limit access and improve performance.
So a simple application can comply with the enterprise architecture but ONLY IF the enterprise invests in providing the application developers enterprise ready components BEFORE the application is being built.
|
-
Being service oriented (SO) is, and continues to prove itself to be, a valuable and elegant approach for applications as well as enterprise architectures. However I am a bit baffled by why an architecture which is service oriented is being branded a new kind of architecture. An architecture may or may not be service oriented but the underlying architecture exists separately. My search for clarity started by trying to pin down a definition for Service Orientated Architecture. The W3C's Web Service Architecture Working Group defines Web Service Architecture as an instance of an SOA in which "a service is viewed as an abstract notion that must be implemented by a concrete agent. The agent is the concrete entity (a piece of software) that sends and receives messages, while the service is the abstract set of functionality that is provided." Well that clears that up, doesn’t it? Equally obscure but I believe more insightful is a definition from Rick Murphy in his article “Centers: The Architecture of Services and the Phenomenon of Life : Christopher Alexander's theory of centers helps explain the essential properties of service-oriented architectures” He invokes Christopher Alexander, one of the original thinkers on architecture, theory’s on centers. Mr Murphy defines SOA as “… services encapsulate the enduring mission of a virtual organization as centers of value. Services, as centers of value, are living structures we choreograph through a common grammar subject to fitness and evolution. Customer demand determines fitness based on service discovery and service description. Choreography defines the sequence and conditions under which services evolve.” I love the abstraction but I think we need a more readily consumable definition. For that I turn to Ramkumar Kothandaraman from Microsoft. In his MSDN article “SOA Challenges: Entity Aggregation” Ramkumar defines SOA as having “several core design principles: - Service boundaries are explicit;
- Services share contracts and schema;
- Services use message-based communication for interaction;
- Services are autonomous and managed independently; and
- Services use policy assertions to control the behavior.”
This works for me. A five point test I can apply to an implementation to gauge is level of SO-ness. Even so, these 5 points are possible characteristics of ANY implemented architecture. Personally, I would add Service Orientated as another style in Roy Fieldings’ dissertation on Architectural Styles and the Design of Network-based Software Architectures. In which he categorizes architectural approaches and weights their appropriateness to a target problem domain. A distributed system can be Layered, implement client caching, AND be service oriented. Considering one can maintain the basic constructs of SO in an embedded, layered, or distributed system it seems clear that the base architecture is not effected by the inclusion or exclusion of services.
|
-
I am a big fan of risk management in all projects. It is however generally rare to see risks identified when developing an enterprise architecture. On the one hand, this seems to make sense. Enterprise architectures are there to address the shared risks for others. They are the cure, not the cause. Unfortunately as cures go, the enterprise architecture is rarely a simple thing and as complexity increases so does the number of opportunities to inject risk.
Consider two primary goals of the Enterprise Architecture, safety and security. All services exposed by the enterprise architecture need to be highly available to the point of ubiquitousness. Failures must be accounted for in planning, minimized by design, and masked from the consumers during operation.
For example an enterprise wide collaboration service might include text messaging, virtual conferencing, and chat. On the surface these are fairly simple and individual user expectations are clear enough. They send a text string to a server and it re-broadcasts that string to the appropriate end points. The risk management plan would minimally address failure to service an inbound request and failure to reach any or all endpoints.
Alas we well know there is much more to it than that. The collaboration service needs to provide a simple facade while securely scaling as required. Load balancing, provisioning, application isolation, authentication and authorization are but a few of the critical yet invisible elements required to support the public interfaces. Each creating new risk opportunities. How will device failures be addressed? Can the business accept lost transmissions or partial text blocks? Will the sessions need to be persisted? If so for how long and how reliably? Addressing these risks adds layering to the architechture, we might consider a replicated repository for identity mnagement, and clustering becomes a real possibilitiy for the data stores.
The risk reduction enjoyed by consumers of a well desighned enterprise architecture come at a price born by the enterprise architecture. Managing these risks well should impact the form and function of the architecture as much, if not more than, the stated requirements coming from the applications. While a bit of a vicious cycle it reinforces the living and iterative nature of the enterprise architecture and the need for continuous evaluation.
|
-
I have mentioned in prior blogs my belief that an enterprise architecture is comprised of 3 intertwined components; standards, governance, and a repository of binaries. I will address standards and binaries later.
For now, I will focus on the concrete manifestation of governance.
Governance differs from standards in 2 important ways;
- While standards provide well known boundaries within which applications are expected to stay, standards will change and applications are expected to stray on occasion. Governance, on the other hand, provides a clear immutable declaration of fact within the context of the enterprise. Governance is inherently stable and exceptions should be few and far between.
- Standards are technical selections, usually one of many possibilities, where any alternative choice is likely to be equally effective. While governance is binary. The only alternative to a given piece of governance is non-compliance.
For example, the preferred development in the enterprise language might be C++, but applications written in C# or visual basic would be equally consumable by users. Making development language a clear candidate as a standard. Conversly. maintaining a measurably high level of security in an environment is a candidate for governance. Applications either are or are not meeting the security metrics.
I like to think of good governance as those policies focused on the management of shared resources as well as policies which provide safety and security to the participating applications in the enterprise.
For kicks, here are a few more candidate governance items;
- typical, average, & maximum network bandwith consumed by an application.
- typical, average, & maximum storage used at the desktop, at local shared servers, near & off-line storage over time (1 -3 -5 years )
- Service levels for various categories (low priority, business necessary , mission critical, & highly available) of applications
- limits on public & internal attack surfaces
- audit & logging requirements and/or limits
- requirements and/or limits on the use of mobile code and remote invocation
- type and source of valid credentials within the enterprise
... More
The devil, as they say, is in the details. Creating and issuing governance for an enterprise requires carefully crafting statements without ambiguity yet reasonable enough to be implemented.
|
-
Most of us can agree that there is always more than one way to achieve a given piece of functionality. Consider getting a phone number for a person from a Sql database.
- You can connect with integrated security, or pass in the username & password, or maybe implement application roles within the database.
- Once connected, you can pass in a fully formed SQL statement, execute a stored procedure, or make a direct http get against a named template file.
- Finally, how will you package the return? An out parameter? A single row in a dataset (or datareader)? Or a typed return from an execute scalar call?
So many possible combinations. Is it possible the developer creating that "quick start" example had your particular circumstance in mind? Seems unlikely doesn't it? It is our responsibility to have a broad understanding of the various approaches and a well defined grasp of the requirements & constraints of the target environment. From these we need to distill the most appropriate combination of technologies, apply the most effective tools, and support our customers’ business needs without burdening them with the side effects of our choices. At the enterprise level, our customers are the aaplication development teams.
Like most things it starts with scope. An enterprise component may be created to constrain or enable its consumers. The important part here is the emphasis on multiple consumers. An enterprise needs to create both massively re-usable parts and multiple interfaces to parts so that one consumer could use it in a web service running on a server while another uses it in a windows form on the client. The additional burden is inescapable and absolutely necessary to support the multiplicity of unknowns.
Sticking with the data access possibilities, the enterprise might define policy explicitly prohibiting passing user name and password in connection strings. It would be kind to backup such a policy with implemental libraries which securely store and retrieve the user name or better yet, append the policy with examples showing exactly how to implement the preferred method(s) which solves the secure data connection problem.
By comparison the application architect has a significantly narrower scope. Constrained by the sweeping policies of the enterprise the application need only identify a single means by which to solve the problem. The application might choose to implement a custom encryption / decryption scheme. Doing so may not create a reusable solution but they comply with the broad enterprise policy (and hopefully achieve the immediate goals of their particular application). It is equally likely that they would adapt some aspect of the current application so that they can use an existing component from the enterprise repository.
At the application level they are free, and strongly encouraged, to choose based on the most expedient and appropriate way to deliver their application. Application architecture simply doesn’t have the luxury of creating and managing highly reusable components. Time pressures, shifting customer requirements, and limited funding drive choice. It is the burden of the enterprise architecture to make compliance something that applications will freely choose to do. If the enterprise architecture (policy, guidance, and binaries) isn’t making it easier the application has every right to ignore it build as they see fit.
|
-
A common phrase used to describe an enterprise architecture is a set of “living documents”. I like it. Short, simple, easy to understand … a living document. Of course there is a dangerously complex implication lying just below the veneer of this simple metaphor. Living implies change and growth. It would seem to need to be feed and cared for. Most importantly it begins as an immature child and develops into a mature contributor to its society.
Those of us who interact with enterprise architectures are affected by the living document metaphor in different ways depending on our role and the maturity of the architecture.
You may be the parent, growing the architecture with new ideas, carefully cleaning away the little day to day dirt and grim that accumulates during the early draft phases. You are its protector, fending off hungry projects looking to gorge on its young unallocated funding. And you are its champion, fighting the good fight. You turn nay-sayers in to supporters with tales of possibilities and the obvious future value your enterprise architecture will provide.
When initiating an enterprise architecture you survey your environment, talking to representative users, reading existing documentation, and studying current systems. You seek the inherent problems the enterprise has in accomplishing the tasks it needs to perform in order to be successful. You boil down the potentially voluminous data gathered and abstract your findings into the conceptual diagrams. You aggregate important policies and standards into a cohesive and broadly applicable guidance document. Applying some well known patterns and a few of your favorite concepts you evolve working documents into drafts and eventually into your proposed architecture. Educated and armed, you lobby superiors, peers, and subordinates to aid you in implementing your new born document.
You may be the doctor, having received an urgent request from the worried parents you make a house call in hopes of identifying and repairing an ailing architecture. Your years of experience, your deep understanding of how architectures work, and of course your calm bedside manner come together to reduce the fears and sooth away the pains. Your prescriptions are sometimes difficult to take and always come with warnings. Crisis averted you can only hope the parents will implement both recommended treatments and get you back for follow up visits.
You might tell yourself “no one calls when things are going well”. It helps fight the cynicism induced by seeing nothing but sick, or failing architectures. Doctoring and enterprise architecture is a fairly predictable process. Assess the situation, calm the managers, gain their confidence, diagnose the most serious of the ailments, prescribe corrective actions, and hope you get the chance to move to a more preventative role. The first three steps are pure soft skills. You need to identify the ‘age’ of the architecture. Are you a pediatrician, a general practitioner, or a gerontologist? Once you understand the context you need clear, truthful information from the locals to begin diagnosing the problems. What are the symptoms? Are they based on real measurable facts (high temperature, low transaction rate) or are they ambiguous (stomach ache, security issues). If the problem is clear you can certainly look at historically successful corrective measures but it is likely you will need to do a few tests first. If the architecture is young you may create a few models to get a better understanding of the issues. If it’s more mature you may use profilers, performance monitors, and debuggers to investigate further. Armed with your test results you can provide the declarative remedy (with the necessary warning of possible side effects and encouragement to call again should symptoms continue or worsen.)
You may be the teacher, seeing the untapped potential in the enterprise architecture; you carefully insert just the right information at the right time. While very young you provide stories of other successful architectures and their exploits. You paint colorful pictures of systems supporting terabytes of data, massive concurrency, very high transaction rates, and global user communities. These are the super heroes of the enterprise architecture world. You can but hope to instill a sense of the possible. Later you begin the monotonous lessons relating rigor, discipline, reviews, change management, and the build process. No glamour, just facts. Hoping to build knowledge on who’s shoulders understanding can later stand.
Being an enterprise architecture consultant is very different than being an enterprise architect. As a consultant we bring our experience, and hopefully the ability to transfer knowledge, to help others so that they may achieve. We don’t build anything. (OK, maybe we build confidence, but that’s not really the point.) Ours is an art of subtle manipulation. We can’t dump a well formed architecture on our customers and expect them to succeed any more than buying a 12 year old a set of encyclopedias and believing they now know everything. The most successful consultants I know have a plan. They know what needs to be addressed first and what needs a foundation in place to be useful. Explaining the intricacies involved in balancing risks, constraints, dependencies, resources against tasks, goals, and metrics is silly if the enterprise lacks basic structure, clear scope, and tools. Teaching takes time … teaching enterprise architecture takes LOTS of time … years, not days. Ours is a commitment to stay the course.
Eventually, the enterprise architecture matures, becoming a stable adult and valuable participant in the larger system within which it lives and works. Its boundaries and capabilities are well defined for all to see and interact with. Less reticent to see a doctor the enterprise invites scrutiny, takes all feedback (the good and the bad) and implements controlled change to integrate it. The prideful arrogance of youth has been replaced with an open team structure. Any and all projects are welcome to use the architecture and more importantly promote parts of themselves into the core architectural constructs.
With age comes rigorous process, clarity of definition, and actionable intent. Mature enterprise architectures have well defined and executed processes in place for continuous improvement. Communication is the cornerstone of the teams working with and on the enterprise architecture. Lessons learned, good and bad, are rapidly communicated to everyone in the enterprise through well known channels. Reviews are sufficient without being onerous on the participants. All in the architecture ambles along a well worn path in a predictable fashion … until the next generation comes on the scene. Then it all begins again.
|
|
|
|
