Enterprise Architecture Frameworks teach us about layers. With the introduction of SOA, should we revisit what we learned? In my recent post about “Layers” and “Patterns”, I was trying to argue the importance of “Services” and their role (as not the only player) in an SOA. With that said, I am being reminded of a diagram I used to see describing Enterprise Architecture Frameworks by decomposing an organization into “Layers”.
Read more…
Pattern-Oriented development is paramount in IT. Patterns are used for designing software [POSA], integrating applications [EIP] or building enterprise systems [PEAA]. They make us feel comfortable that are our solution in the end will be extensible, reusable and hopefully along the way we managed avoiding some age-old pitfalls.
Read more…
Does your integration solution provide value or cause problems? This question obviously presumes your business has some type of “solution” to integration, and it does. Every system of information technologies from stand-alone applications to document management to enterprise provisioning must solve the “connectivity” problem. This may be simple emails, multiple database interfaces, full blown EAI or just person-to-person interaction – the concept is the same: you must be able to communicate data. So does your implementation of integration solve the problems facing your business? How about problems other than purely connectivity? Or is integration another hurdle stopping you from the next enhancement or even worse, costing your business dollars due to poorly designed interactions?
Read more…
Is an integration project merely a matter of connectivity – making n-number of applications transfer data? By this logic the project’s success is binary: it connected the systems or it did not. Anyone involved in systems integration at any level understands that what it means to be “connected”, itself, quickly becomes an abstract term with multiple meanings. Enter in SOA and most have no clue what the goal is.
Read more…
