tag:blogger.com,1999:blog-7826786244968404549.post7317728298332663520..comments2023-09-05T23:58:35.122-07:00Comments on Simple Architectures for Complex Enterprises: Snowman Architecture Part One: OverviewRoger Sessionshttp://www.blogger.com/profile/16946430426943308823noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-7826786244968404549.post-80844765456010680352013-08-18T23:29:05.413-07:002013-08-18T23:29:05.413-07:00Hey I my friends I tell you something can you give...Hey I my friends I tell you something can you give me answer please Many of your business owner clients have a depth of knowledge and expertise in their own businesses but must rely on an integrated group of trusted advisors such as lawyers, accountants, financial advisors, insurance professionals, investment bankers and others. Many of your clients undoubtedly end up frustrated and angry at mounting legal and accounting expenses. What many business owners do not understand is that often the causes of seemingly out-of-control third party bills originate in their own shop and have to do with their own inadvertent mismanagement of external advisors.<br /><a href="http://lazercad.com/" rel="nofollow">architecture or business blogs</a>Anonymoushttps://www.blogger.com/profile/08950158913509450940noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-69375445659515066522013-07-07T23:41:30.913-07:002013-07-07T23:41:30.913-07:00Have you looked at the Domain Driven Design by Eri...Have you looked at the Domain Driven Design by Eric Evans along with extensions like CQRS pattern promoted by Greg Young and Udi Dahan? <br /><br />Bhplibhttps://www.blogger.com/profile/13640392777812036961noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-5915154828750394232012-10-19T06:36:01.661-07:002012-10-19T06:36:01.661-07:00Hi Roger.
Nice article (i've read part 2 also...Hi Roger.<br /><br />Nice article (i've read part 2 also)<br /><br />What you are describing, to my mind, however, is an extremely effective way to think about *solutions* architecture, and also a great paradigm for quick and effective M&A work.<br /><br />As an *EA* methodology however, i'd want to know a lot more about how all these snowmen hold hands in the field where they are sat.<br /><br />Presumably you'll address that in parts 3 and 4?<br /><br />But it's a nice thought model to deal with a set of business capabilities and needs, and the data/information/application value chain which supports them...<br /><br />Reading it, i must say, i started to laugh as i considered a mental picture of shared data sources and coupled capabilites being dually addressed by two snowmen, who now had to get... umm... intimate...<br /><br />Especially as snowmen are known to be frigid:)Nichttps://www.blogger.com/profile/11590545505293730733noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-77942262348919136612012-09-20T12:08:47.173-07:002012-09-20T12:08:47.173-07:00Dave, Nigel,
Given that the torso of the snowman (...Dave, Nigel,<br />Given that the torso of the snowman (the technical architecture) is a projection of the head of the snowman (the business architecture), and that the arms of the snowman (messages) directly implement business dependencies, it is hard for me to see how there is a disconnect between the business and technical perspectives on the data.<br /><br />As Nigel points out, this is very similar to the software fortress architecture that I proposed a number of years ago. I think of this as an update incorporating what I have learned about complexity since then. <br />Roger Sessionshttps://www.blogger.com/profile/16946430426943308823noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-58127131894418265392012-09-20T01:41:10.364-07:002012-09-20T01:41:10.364-07:00Using pub-sub to address the data issue can be eff...Using pub-sub to address the data issue can be effective if the messaging model is canonical, and specifically if the canonical message model is aligned to the business' view of their information. (Typically the information model).<br /><br />This leads to interesting side effects, but there are several canonical patterns to consider when adopting this model, Including Russian Doll, Venetian Blind and Salami Slice..<br /><br />We are using a canonical message approach to solve this exact problem (as well as others). Its early days yet, but the so far the approach is holding up well. In our implementation, the only way data is allowed to move between "snowmen" (actually s/w fortresses structured very similarly to snowmen) is via the pub-sub system which enforces the use of canonical messages.Nigel Bakkerhttps://www.blogger.com/profile/02439872673818341079noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-45289936245592216102012-09-14T02:49:48.833-07:002012-09-14T02:49:48.833-07:00I Agree Dave.
TOGAF uses Business -> Informatio...I Agree Dave.<br />TOGAF uses Business -> Information -> Technology.<br /><br />I think it is the difference between the thinking model and the physical model.<br /><br />You think in BIT architecture.<br />You work in BTI architecture.<br /><br />Johan Theunissen<br /><br />When you think, technology is a means to information, and information an means to business.<br /><br />When you actually are working, the business must have acces to technology to acces the information. So the information is behind the technology.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-71519199748818371962012-09-06T09:01:16.006-07:002012-09-06T09:01:16.006-07:00This seems to suffer from the same problem that SO...This seems to suffer from the same problem that SOA suffers from. You have data on the other side of the technology from the business, instead of being derived from the business. This suggests that the data architecture will be based on the technological architecture. <br /><br />This is exactly the flaw that results in the issues raised above. <br /><br />You can't have a message-based system if you haven't previously addressed what the messages contain. If the sender and receiver send a message but the meaning understood by the sender is different from the meaning understood by the recipient, things will "go south" quickly. <br /><br />This means a model is required to decode the structure of the business data. This model will cross applications. It will <i>not</i> be based on technnology. Doing this <i>precedes</i> setting up the SOA architecture.Dave Hayhttp://essentialstrategies.comnoreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-55421975136986888882012-09-04T04:47:34.590-07:002012-09-04T04:47:34.590-07:00Sze Siong Teo,
That is a great question. Dealing w...Sze Siong Teo,<br />That is a great question. Dealing with the data partitioning is one of the biggest challenges in The Snowman Architecture. But there are a number of patterns that can help. The most obvious is "ask and you shall receive" in other words, send a message to an ABC asking for the data you want. <br /><br />Another useful pattern is "subscribe and publish", that is, an ABC regularly publishes information that it thinks others might find interesting and those that want it subscribe to the publications. <br /><br />Yet another is "central data heap", that is an ABC whose responsibility it is to maintain read-only copies of up-to-date enterprise data that can be easily queried.<br /><br />With the Snowman Architecture, we do tend to end up with copies of data. But unlike the traditional relational "third normal form" we don't worry about having copies of data, we only worry about making sure those copies are kept consistent. Roger Sessionshttps://www.blogger.com/profile/16946430426943308823noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-64740657047446099872012-09-03T07:57:55.345-07:002012-09-03T07:57:55.345-07:00In real world scenario, very often there is data t...In real world scenario, very often there is data that lies somewhere in the 'gray area' whether which system or systems should have the ownership of it. Exchanging messages/data between the Snowmans might not be a simple case or efficient thing to manage as the amount of data and Snowmans increased. Can you highlight how to overcome the challenges of maintaining the complexity at a constant rate for data exchange/messaging between different 'Snowmans' as the amount of data and 'Snowman' increases?Anonymoushttps://www.blogger.com/profile/17315533431510500456noreply@blogger.com