Comments on: Thoughts from an enterprise architect http://www.bridging-the-gap.com/thoughts-from-an-enterprise-architect/ Advance Your Business Analysis Career Thu, 09 Feb 2012 00:08:14 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: DougGtheBA http://www.bridging-the-gap.com/thoughts-from-an-enterprise-architect/comment-page-1/#comment-2929 DougGtheBA Thu, 03 Sep 2009 15:46:36 +0000 http://www.bridging-the-gap.com/?p=1634#comment-2929 Remember the old rule, keep the whats (Requirements) separate from the Hows (Design). By doing this AND tracing between the two, one amasses a broadened view of the architecture and infrastructure. So, if the org decides to implement the same set of requirements in a brand new way, there is still an understanding of what the core functionality is. Remember the old rule, keep the whats (Requirements) separate from the Hows (Design). By doing this AND tracing between the two, one amasses a broadened view of the architecture and infrastructure. So, if the org decides to implement the same set of requirements in a brand new way, there is still an understanding of what the core functionality is.

]]> By: Laura Brandau http://www.bridging-the-gap.com/thoughts-from-an-enterprise-architect/comment-page-1/#comment-2928 Laura Brandau Thu, 03 Sep 2009 15:33:03 +0000 http://www.bridging-the-gap.com/?p=1634#comment-2928 Hi Doug, No worries...be as critical as you feel appropriate! I don't think anything is going to happen to this wedding. :-) You bring up some good points on how a web services architecture also can be served by good requirements traceability. Our organizations are getting more interwoven and complex and with that so are the systems that support them. I'd be interested to hear how you'd approach modeling a web services design in a requirements traceability matrix. Is there a way to keep all of these entities in sync at a requirements level or is it really a design traceability? Laura Hi Doug,
No worries…be as critical as you feel appropriate! I don’t think anything is going to happen to this wedding. :-)

You bring up some good points on how a web services architecture also can be served by good requirements traceability. Our organizations are getting more interwoven and complex and with that so are the systems that support them. I’d be interested to hear how you’d approach modeling a web services design in a requirements traceability matrix. Is there a way to keep all of these entities in sync at a requirements level or is it really a design traceability?

Laura

]]> By: DougGtheBA http://www.bridging-the-gap.com/thoughts-from-an-enterprise-architect/comment-page-1/#comment-2927 DougGtheBA Thu, 03 Sep 2009 15:21:56 +0000 http://www.bridging-the-gap.com/?p=1634#comment-2927 When reading your post with David, I had in the back of my mind many concepts that also pushed me to write my recent article: The Value of Requirements Traceability http://bit.ly/406hQ6. Your post ties nicely into these concepts by describing how organizations are using new technologies to bring forward new capabilities. Therefore, it's critical to understand core capabilities in a system before altering them or exposing them across an enterprise... or even external to the enterprise. David's answers regarding web services illustrate this very well, "web services make it possible to have a single piece of code that is consumed by multiple pages" Reuse and enterprise exposure of core elements has been rapidly changing not only how users interact with systems, but also the way in which those systems are constructed and accessed. To your question about how analysts can improve their work with developers, I'd like to offer the suggestion of collaborative accountability. The two roles should work together in these development scenarios to fully understand impacts to systems and core functionality prior to and during the implementation of changes like the ones David described. To bring this suggestion full circle, the method to accomplish this during the collaboration is requirements traceability. BTW....you're really setting us up here. Even if I had negative criticism of this post, I could never tell you without fear of causing the wedding to be called off.:) When reading your post with David, I had in the back of my mind many concepts that also pushed me to write my recent article: The Value of Requirements Traceability http://bit.ly/406hQ6.

Your post ties nicely into these concepts by describing how organizations are using new technologies to bring forward new capabilities. Therefore, it’s critical to understand core capabilities in a system before altering them or exposing them across an enterprise… or even external to the enterprise. David’s answers regarding web services illustrate this very well,

“web services make it possible to have a single piece of code that is consumed by multiple pages”

Reuse and enterprise exposure of core elements has been rapidly changing not only how users interact with systems, but also the way in which those systems are constructed and accessed. To your question about how analysts can improve their work with developers, I’d like to offer the suggestion of collaborative accountability. The two roles should work together in these development scenarios to fully understand impacts to systems and core functionality prior to and during the implementation of changes like the ones David described. To bring this suggestion full circle, the method to accomplish this during the collaboration is requirements traceability.

BTW….you’re really setting us up here. Even if I had negative criticism of this post, I could never tell you without fear of causing the wedding to be called off.:)

]]>