SEI Insights

SATURN Blog

SEI Architecture Technology User Network (SATURN) News and Updates

SATURN 2014 Architectural Modeling Session (notes)

Posted on by in

Notes by Ziyad Alsaeed, edited by Tamara Marshall-Keim Expanding Legacy Systems Using Model-Driven Engineering (MDE) William Smith, Northrop Grumman Kevin Nguyen, Northrop Grumman Kevin Nguyen and his fellow engineers faced a common problem of dealing with legacy systems. At their environment (Northrop Grumman), they are dealing with rigid defense systems. Kevin tried to adapt a model-driven engineering approach in his work to achieve his goals. The team used conceptual software architecture to help understand customer requirements. Next, they refined the requirements into a CSCI architecture of software and hardware. Then, they tried to expand the CSCI architecture into CSC architecture (more detailed and lower level models). Finally, the team tried to convert that into a detailed design for the software unit. They went through these steps following a basic procedure of software-design life cycle.

Through their experience, they were able to pass military quality-assurance regulations. In addition, they minimized system-integration issues and increased testability. They were able also to obtain object-oriented design benefits from non-object-oriented legacy systems. Moreover, and most important, they were able to create a platform for communication and collaboration among different software teams’ entities (e.g., test, development) within their organization. Throughout adapting this process, there were some challenges, some of which were related to adopting new tools and training the team. Also, changing the team process and culture to shift into a more MDE approach was challenging at different levels such as source control and requirement management. Convincing the organization of the long-term benefits of adapting MDE also was a challenge. Presentation link: http://resources.sei.cmu.edu/asset_files/Presentation/2014_017_101_89506.pdf Identifying and Protecting Architecturally Significant Code Mehdi Mirakhorli, DePaul University Jane Cleland-Huang, DePaul University Mehdi’s research is concerned with source-code erosion from the intended architecture plan. He provided different examples of the well-known systems that shifted from the intended architectural plan. Usually such erosion doesn’t happen overnight. However, different developers will make different changes at different times. Such changes could eventually (and they actually usually do) cause architectural decay. And eventually the system source code will become what’s known as “spaghetti code.” The consciences of such erosion are usually severe and cost several hundreds of thousands dollars on average. Mehdi’s proposal is to find a way to enforce the developer to always think about the architecture and the rationale behind the source code. To achieve that, he came up with “Archie.” Archie is a smart Eclipse IDE plugin that will show a visualization of the architecture next to the source code. And more important, it has the intelligence to warn the developer of any architectural violation that could happen based on the developer’s change by performing change-impact analysis. There is still more work to be done to reach an effective way. For example, the change-impact analyzer could be improved to be more accurate and smarter. Presentation link: http://resources.sei.cmu.edu/asset_files/Presentation/2014_017_101_89669.pdf Large-Scale Service-Oriented Architecture with a Central Service Repository: Success, Learning, and Challenges Georg Huettenegger, Credit Suisse Georg is dealing with a significantly distributed company. His major goal is to provide a maintainable service-oriented architecture repository that will serve thousands of clients globally within his organization. To overcome some challenges, Credit Suisse adapted a business-oriented service module. Given that, there are still some technical challenges with SOA scalability. They overcome this issue by applying different technical techniques. To reach the scalability and stability that they now have, they had to learn the hard way. As lessons they learned from that experience, they believe people should think about the following:

  • Ambiguity in core SOA concepts is nearly impossible to change or fix.
  • Having a mature offering can be negative.
  • Just selling SOA does not work outside your local environment.
  • Tight security integration can be an adoption hurdle.
  • SOA needs accepted decoupling boundaries.
On top of that, they think teams should deliver quickly and show success as soon as possible to demonstrate the immediate benefit for upper management. Linking the benefits to the company target could also help gain management approval.

About the Author

Bill Pollak

Contact Bill Pollak
Visit the SEI Digital Library for other publications by Bill
View other blog posts by Bill Pollak

Comments

Policy

We welcome comments with a wide range of opinions and views. To keep the conversation focused on topic, we reserve the right to moderate comments.

Add a Comment

Comments*


Type the characters you see in the picture above.