Making Enterprise Architecture real; Step 5 treasures from our information safari- November 24, 2004 Back from our information safari, its time to munge (thats 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...http://blogs.msdn.com/stcohen/archive/2004/11/24/269343.aspx Making Enterprise Architecture real; Step 4 Seeking domain understanding- November 23, 2004 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...http://blogs.msdn.com/stcohen/archive/2004/11/22/268255.aspx Making Enterprise Architecture real; Step 3 selecting abstract & domain components- November 15, 2004 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 isnt an item Documents, supplies, parking spaces, are all items in their own way. The danger is in...http://blogs.msdn.com/stcohen/archive/2004/11/14/257290.aspx Making Enterprise Architecture real; Step 2 separating domain from plumbing components- November 7, 2004 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...http://blogs.msdn.com/stcohen/archive/2004/11/07/253573.aspx Making Enterprise Architecture real ; Step 1- who owns what- November 3, 2004 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.http://blogs.msdn.com/stcohen/archive/2004/11/02/251411.aspx Can an application really be simple AND comply with an Enterprise Architecture- November 1, 2004 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() ...http://blogs.msdn.com/stcohen/archive/2004/11/01/250639.aspx |